Linux 5.3-ck1 Kernel Released With MuQSS 0.195 Scheduler Bringing Ryzen Fixes

[phoronix]

Phoronix: Linux 5.3-ck1 Kernel Released With MuQSS 0.195 Scheduler Bringing Ryzen Fixes

Con Kolivas is normally quite quick following new kernel releases in turning around a re-spin with his patch-set atop that also has his MuQSS scheduler optimized for desktop responsiveness. His Linux 5.3 kernel support is late to the party due to being tied up with other work, but Kolivas introduced his latest code today...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.3-ck1-MuQSS-0.195

[bezirg]

Hi Michael, yes I am interested in new -ck benchmarks! Does this muqss LLC option target only zen2, or also zen, zen+ cpus? It would be interesting to see how this new option affects ryzen.

[ermo]

I'd be interested in seeing distro kernels (e.g. fedora/ubuntu kernels) vs. -ck1 benchmarks with mq-deadline vs. mq-bfs on each, using some older systems with SATA SSDs (FX-6/8xxx + i5/7-2/3/4xxx maybe?). Bonus points for including mitigations and no mitigations. Use 8GB RAM and the same older dGPU for each box and run the benchmarks under GNOME Shell 3.34 on Xorg with a single monitor.

This could be a good proxy for demonstrating what the average Linux user on older hardware can expect. Not everyone runs brand spanking new boxes with NVMe storage.

Maybe have an 8-core RyZen 3xxx box w/new GPU and NVMe as a reference just for kicks.

EDIT: Personally, I'd be interested in seeing compilation/compression/encoding/usb-(image-)transfer loads in the background combined with opening various apps (firefox, libreoffice, terminal, video-playback from disk, opening pdf from disk). This should cover the majority of daily use cases nicely?

[wizard69]

Great but I only run kernels supplier by my distro. In this case Fedora. Makes me wonder if there is a distro out there that uses these patches by default.

Speaking of defaults, has anybody tried to simply set the timer to 100Hz to improve responsiveness? I’m still of the opinion that a Good GPU makes a huge difference in desktop feel so I’m not sure this would have a huge impact.

[Cybmax]

Great but I only run kernels supplier by my distro. In this case Fedora. Makes me wonder if there is a distro out there that uses these patches by default.

Speaking of defaults, has anybody tried to simply set the timer to 100Hz to improve responsiveness? I’m still of the opinion that a Good GPU makes a huge difference in desktop feel so I’m not sure this would have a huge impact.

Setting 100Hz is the OPPOSITE of responsiveness... Lower Hz = more throughput vs. higher Hz = quicker taskshifting and whatnot (ie. responsiveness). What the -ck patches do is to keep responsiveness at 100Hz so you gain the benefit of throughput. Atleast that is the idea i guess.

I would like to see the comparison between stock <-> -ck <-> BMQ and possibly TK-Glitch patched kernel with PDS. That would be a fun exercise.

I have tested the lot, and i do like -ck/MuQSS a lot. Since i upgraded to 5.3 before Con had the patches ready, i ended up trying the PDS fixed for 5.3 that is on the TKG pkbuild patches with good result. Personally i tend to not like too many knobs to turn, as i just end up benching stuff all day long testing various settings. And benchmarking is in nature somewhat within variance, and i have spent too much time doing that heh.
One nifty thing to test when benching cpu schedulers (atleast imo) is doing a -j4 or something compile while benchmarking things like Unigine Valley or similar. This way you kinda use the scheduler for something.

Lets say your game uses 2-3 cores, and doing a -j4 compile on a 8 thread cpu, you should in a perfect non-existant world not loose any fps, nor should the compile take any longer than if you did not run the game.... That is if the scheduler is "perfect". This won't happen ofc, but there is great differences between PDS/BMQ/MuQSS from what i have tested.

So if a scheduler comparison should be done, a test like that would be very interesting for me Michael

[Vistaus]

Setting 100Hz is the OPPOSITE of responsiveness... Lower Hz = more throughput vs. higher Hz = quicker taskshifting and whatnot (ie. responsiveness). What the -ck patches do is to keep responsiveness at 100Hz so you gain the benefit of throughput. Atleast that is the idea i guess.

I would like to see the comparison between stock <-> -ck <-> BMQ and possibly TK-Glitch patched kernel with PDS. That would be a fun exercise.

I have tested the lot, and i do like -ck/MuQSS a lot. Since i upgraded to 5.3 before Con had the patches ready, i ended up trying the PDS fixed for 5.3 that is on the TKG pkbuild patches with good result. Personally i tend to not like too many knobs to turn, as i just end up benching stuff all day long testing various settings. And benchmarking is in nature somewhat within variance, and i have spent too much time doing that heh.
One nifty thing to test when benching cpu schedulers (atleast imo) is doing a -j4 or something compile while benchmarking things like Unigine Valley or similar. This way you kinda use the scheduler for something.

Lets say your game uses 2-3 cores, and doing a -j4 compile on a 8 thread cpu, you should in a perfect non-existant world not loose any fps, nor should the compile take any longer than if you did not run the game.... That is if the scheduler is "perfect". This won't happen ofc, but there is great differences between PDS/BMQ/MuQSS from what i have tested.

So if a scheduler comparison should be done, a test like that would be very interesting for me Michael

I tested -ck a while ago, but I found it to be slower than the standard Arch kernel. So I switched to the Linux Clear kernel on Arch (available through AUR) instead and my system is almost unbelievably fast now

[polarathene]

A good scheduler bench/review would be great to see!

I tested -ck a while ago, but I found it to be slower than the standard Arch kernel.

Slower in what way? Higher latency or I/O? One drawback of MuQSS iirc is support for cgroups is dropped.

[ermo]

Great but I only run kernels supplier by my distro. In this case Fedora. Makes me wonder if there is a distro out there that uses these patches by default.

I haven't seen any mainstream distributions include them by default. The liquorix kernel for Debian-based distributions essentially ship with the -ck1 patchset plus a few extra changes (including the BFQ I/O scheduler by default) it seems?

I don't know if anyone is maintaining a liquorix-like kernel for Fedora.

[Gusar]

Setting 100Hz is the OPPOSITE of responsiveness... Lower Hz = more throughput vs. higher Hz = quicker taskshifting and whatnot (ie. responsiveness). What the -ck patches do is to keep responsiveness at 100Hz so you gain the benefit of throughput.

From the ck patchset:

100 Hz is a suitable choice in combination with MuQSS which does
not rely on ticks for rescheduling interrupts, and is not Hz limited
for timeouts and sleeps from both the kernel and userspace.
This allows us to benefit from the lower overhead and higher
throughput of fewer timer ticks.

So yes, higher throughput, but with MuQSS it's not at the expense of responsiveness.

[retardxfce]

Would there be any benefit running MuQSS with 1000HZ tick?