The Latest On The Linux 5.9 Kernel Regression Stemming From Page Lock Fairness

[phoronix]

Phoronix: The Latest On The Linux 5.9 Kernel Regression Stemming From Page Lock Fairness

Last week we reported on a Linux 5.9 kernel regression following benchmarks from Linux 5.0 to 5.9 and there being a sharp drop with the latest development kernel. That kernel regression was bisected to code introduced by Linus Torvalds at the start of the Linux 5.9 kernel cycle. Unfortunately it's not a trivial problem and one still being analyzed in coming up with a proper solution. So the short story is it's a work-in-progress while this article has some additional insight and benchmarks done over the course of the past few days.

http://www.phoronix.com/vr.php?view=29500

[Etherman]

Very interesting!

[dxin]

The follow up solution will be very interesting.

[GreenByte]

That's interesting stuff. The first idea that came to mind was to switch between the 2 behaviours. Upon one unlock, allow the fastest process to snatch the lock, upon the second one - give it to the queued process. I'm sure the proportions could be tuned, some cleverness could be added, but it could make it the best of 2 worlds (if it is not a horrible idea).

[indepe]

Let the thread that wants to jump ahead do the work of the sleeping thread... ;-)
Maybe a use case for the FUTEX_SWAP proposal that was recently discussed.
(Actually it wouldn't be exactly FUTEX_SWAP, but something similar.)

[reavertm]

Doesn't Linux Kernel project have any CI running on every commit in selected branches so things like that could be picked without relying on Michael run performance regression tests occasionally? Come on, it's 21st century.

[Michael]

Doesn't Linux Kernel project have any CI running on every commit in selected branches so things like that could be picked without relying on Michael run performance regression tests occasionally? Come on, it's 21st century.

There is the kernel CI albeit only so verbose to do on a per-commit basis.... The tests I started out with originally for my comparison were taking more than 24 hours on a high-end server, hence not really applicable for per-commit (or largely per-day) testing.

[reavertm]

There is the kernel CI albeit only so verbose to do on a per-commit basis.... The tests I started out with originally for my comparison were taking more than 24 hours on a high-end server, hence not really applicable for per-commit (or largely per-day) testing.

Well, you are running full blown real-world applications in that regression suite. For sure that is not suitable for per-commit CI even if it took just an hour though one could still run them on feature branch merges, I doubt it happens very often.

[cjcox]

I was digging through the Windows code and I saw some of the issue that cause wuauserv and WsoSvc to either stop responding, or consuming memory or consuming CPU without actually doing anything useful. I submitted some patches that I believe will fix most of that.

(now back to reality)

[Elktron]

Speaking of fairness, I don't think its fair to us tht we should have to main the trade off between throughput and latency spikes