Linux Kernel "Zen" Downstream Pulls In A MuQSS Fix To Help Gaming Performance

[Vistaus]

Not OP, but these were a couple I ran into the other day that might be of interest though I haven't had a chance to test them out.

CFS cpu usage fix:
https://git.kernel.org/pub/scm/linux...913433b6d9b0b6
https://git.kernel.org/pub/scm/linux...4387f7ca38e773
-> Easy to boost CFS performance w/ nr_migrate = 128 (32 default).

~$ echo 128 | sudo tee /proc/sys/kernel/sched_nr_migrate
https://github.com/xanmod/linux/comm...7c493c2d381c76

Thanks!
Do I have to "echo" this after every reboot or does it persist?

[Britoid]

Thanks!
Do I have to "echo" this after every reboot or does it persist?

You'll have to make it persist by adding it to a sysctl file.
kernel.sched_nr_migrate=x

[danoam]

I currently use the Liquorix (Zen for Ubuntu) kernel, not because I need/want those scheduler tweaks etc, but simply because it includes the Valve fsync (for wine/proton) patches. I'd use esync instead, but the game I want to play regularly freezes when using esync. And the default wineserver-based sync implementation is a bit slow. For some reason Valve only provides compiled fsync kernels for outdated Ubuntu 19.04 and the last LTS, not for the current STS release 19.10…

You can apply the fsync patch to your own kernel if you like https://github.com/Tk-Glitch/PKGBUIL....4-fsync.patch

[hax0r]

Would you mind sharing your CFS and I/O scheduler tweaks?

I don't use anything special, CFS, 1000Hz rate, full preemptible kernel, bfq low latency I/O scheduler, fsync Valve patch, ClearLinux patches, and -O3 gcc patch. For userspace I compile everything with LTO and graphite (gentooLTO overly).

[ext73]

I don't use anything special, CFS, 1000Hz rate and bfq low latency I/O scheduler, fsync Valve patch, ClearLinux patches, and -O3 gcc patch. For userspace I compile everything with LTO and graphite (gentooLTO overly).

You can further increase performance, responsiveness and improve energy efficiency, e.g. Lenovo 720-IKB i7 8550u + 8 GB ram + Nvidia MX150> CS: GO - kernel Premium series on our NeteXt'73 [our solutions for Ubuntu]:

https://www.dropbox.com/sh/vzxz6g25e...XvRtH-v2a?dl=0

[nranger]

Thanks!
Do I have to "echo" this after every reboot or does it persist?

]$ sudo echo "kernel.sched_nr_migrate = 128" > /etc/sysctl.d/30-core_sched.conf

to make a sysctl value get auto-loaded on boot. 'sysctl -a' to get a list of sysctl values that your system supports.

[timofonic]

You can further increase performance, responsiveness and improve energy efficiency, e.g. Lenovo 720-IKB i7 8550u + 8 GB ram + Nvidia MX150> CS: GO - kernel Premium series on our NeteXt'73 [our solutions for Ubuntu]:

https://www.dropbox.com/sh/vzxz6g25e...XvRtH-v2a?dl=0

Please don't get me wrong, but it looks like snake oil to me...

[polarathene]

It would also be interesting to test -O3 vs. -O2 and full tickless vs. 1000Hz vs. default.

Digging up my old notes on MuQSS, there's apparently no benefit to tickless, and also when using MuQSS without the complimentary CK patches(that you'd get with CK kernel vs liquorix/zen afaik?), you might encounter other disadvantages?

http://ck-hack.blogspot.com/2018/12/linux-420-ck1-muqss-version-0185-for.html

The author states the following, but it does not mean a tickless kernel(do not use with CONFIG_NO_HZ_FULL, use CONFIG_NO_HZ_IDLE=y)

Perhaps the ck patches should become part of muqss since muqss is intrinsically a tickless scheduler and relies on highres timeouts to work properly, but unfortunately the highres timers in mainline are stupidly tick resolution limited...

The disadvantage is not clear, but apparently it messes with the "accounting"(accuracy?) thus may affect CPU states and governors(power management/frequency?)

I keep trying to tell people to not make completely tickless kernels. No idle ticks is ideal for MuQSS. There is no advantage to a completely tickless kernel even for mainline for a normal desktop or mobile device.

...

Some audio distortion in WINE that I eventually solved by recompiling the kernel with full periodic ticks.

A user mentions an issue with console input for their encryption pass code during boot as keypresses "bounce":

I used to have this issue too, it was probably solved by enabling periodic timer ticks - CONFIG_HZ_PERIODIC=y

Some additional notes in markdown that I'm just going to copy/paste instead of convert:

From March 2019 5.0 kernel release:

http://ck-hack.blogspot.com/2019/03/linux-50-ck1-muqss-version-0190-for.html#comment-form

> I have the problem that on (pre-Ryzen) AMD CPUs, the clock speed is always on max with schedutil on the MuQSS patchset
> Seeing the same phenomenon. NO_HZ_IDLE, 100 Hz, MuQSS, schedutil and all 4 cores at max clock 100% of the time.
> With CFS instead of MuQSS, the core clocks behave normally.
> Measured with a `watch -n1 of cat /proc/cpuinfo` over some time.
> Seeing the same here; other software-based governors functioning as expected, schedutil simply not functioning at all.
> schedutil is so far ahead of its competitors, would be wonderful to see it functioning as expected in conjunction with MuQSS.
> At least, in conjunction with MuQSS. 100% max clock on all cores, 100% of the time.
> Since it cannot be entirely ruled out at this point that schedutil simply never worked correctly in conjunction with MuQSS.

> I understand that for low latency 'MuQSS + high res timers' (aka ck1 patchset) is better than MuQSS alone.

Scheduler throughput benchmark comparison PDS/BMQ/MuQSS(with CK patches and separate) vs CFS:

https://docs.google.com/spreadsheets/d/163U3H-gnVeGopMrHiJLeEY1b7XlvND2yoceKbOvQRm4/edit#gid=96437269

> Some further confirmation for you, Liquorix uses MuQSS and disabled tickless idle a long time ago: https://github.com/damentz/liquorix-...ig-arch-64#L85

> I've settled on 250hz since it gives decent timekeeping without the the negative affects on power consumption that 1000hz causes.

---

MuQSS doesn't appeal to me anymore, it uses 20% more CPU usage for 2% boost in FPS, not worth it

MuQSS doesn't support cgroups either, not to mention it skews load avg readout and reports otherwise idle system having ~0.97 load avg

See above, it may not have actually been extra 20% CPU usage as the way MuQSS works can be inaccurately read by such metrics.

As for cgroups, that's not entirely true. It does support some afaik, and others are not implemented/stubbed I think, which can cause problems(such as with PSI I think), but some cgroups should work ok when MuQSS is in use, I wouldn't mind a list of what is and isn't properly supported though.

All I have regarding that is the following from Con Kolivas:

http://ck-hack.blogspot.com/2018/12/linux-420-ck1-muqss-version-0185-for.html?showComment=1547195219042#c5181301935285599329

No, docker and containers that use CPU scheduler cgroups in general do not work at all with MuQSS. There is no 'containment' as such, and the cgroups are only there to allow systems to run that mandate their existence.

Someone else afterwards points out it's due to the cpuacct cgroup controller, the Arch Wiki also has this to say:

It is a common mistake to think that MuQSS does not support cgroups. It does but not all the cgroup features (e.g. CPU limiting will not work).

Official docs on MuQSS do suggest otherwise though(is it just cgroups related to CPU that this scheduler would be usually responsible for?):

What MuQSS does not now feature is support for CGROUPS. The average user should neither need to know what these are, nor should they need to be using them to have good desktop behaviour. However since some applications refuse to work without cgroups, one can enable them with MuQSS as a stub and the filesystem will be created which will allow the applications to work.

MuQSS itself is meant to be focused on responsiveness for desktop users, so these issues aren't considered as problems with MuQSS by the author afaik? Unfortunately that does make it a little less attractive for some users since it can lead to utilities reporting false information or not working properly(eg limiting CPU activity with cgroups). While not yet confirmed, there is a case with the nohang project(like oomd/earlyoom projects) with a MuQSS user that appears to be due to the lack of proper cgroup support causing PSI to fail. PSI itself doesn't need cgroups to function, but I believe it's noticed MuQSS has those stubs enabled, and attempted to use that support.

I'd be interested in how BMQ or PDS compare to MuQSS, no idea if they handle cgroups better.

[hax0r]

You can further increase performance, responsiveness and improve energy efficiency, e.g. Lenovo 720-IKB i7 8550u + 8 GB ram + Nvidia MX150> CS: GO - kernel Premium series on our NeteXt'73 [our solutions for Ubuntu]:

https://www.dropbox.com/sh/vzxz6g25e...XvRtH-v2a?dl=0

You should run benchmark before/after applying your tweaks. I read your blog https://www.netext73.pl/2014/02/kernele-e-x-t-7-3.html where you mentioned that you're being able to accomplish all 4 of these at the same time: 1) maximum responsivity, 2) maximum efficiency, 3) lowest energy usage, and 4) maximum security. Sorry to burst your bubble but your kernel is neither of those 4, you can't have all 4, maybe at most 3 out of 4 but probably closer to 2 out of 4, but nonetheless cool website and project, you probably learned a lot along the way.

[Isedonde]

You can apply the fsync patch to your own kernel if you like https://github.com/Tk-Glitch/PKGBUIL....4-fsync.patch

I'm aware of this, but I don't want to compile my own kernel. My hardware is outdated and compiling things takes way too long, so I'll only compile my own projects, or things that I HAVE to compile. Since Liquorix provides a pre-compiled and up-to-date kernel, I simply use that and hope that Valve/their partners succeed in upstreaming/mainlining fsync patches soon, or maybe Ubuntu applies those patches to their distro kernel. :-)

I googled the guy who posted the patches to LKML, and it seems like he's still working on it, but also has other tasks on his hands, so hopefully he can find some time to propose a new patch set addressing the issues mentioned on LKML.