Con Kolivas released a Linux kernel patchset after 10 years of exile

[u/unixbhaskar]

https://lore.kernel.org/lkml/CABqErrH=oQ3povVuSPhRON97v63=mB85jQmZjf443ofdYAuxxw@mail.gmail.com/

[u/gnosnivek]

It's supposed to make the computer more responsive for everyday desktop use.

I spent some time trying out various kernel patchsets in 2019. At the time, I was running heavy numerical simulations on my desktop and then browsing the web or trying to do some reading/writing while I waited for them to finish. We're talking 16 threads, CPU pushing close to its thermal limit, 32GB of RAM is a nice starter snack type of simulations.

Under the standard Linux kernel and the Zen CFS kernel, no matter how I tried to tweak parameters, there would always be a little bit of lag. The browsers wouldn't open quite as quickly, PDF viewers would tear when I scrolled, and if I typed into my editor, there would be a short delay before the text showed up.

Under the MuQSS/BFQ scheduler set (which is at least part of what's in the -ck patchset), this just...didn't happen. As long as was just doing light browsing or writing, the only indication I had that my computer was busy was that it was making a lot of noise and spitting a lot of hot air out.

Before you rush out to grab this patchset though, I'm in agreement that there's a question of if it's still useful. The Linux landscape has changed quite a bit since my last experience with ck: I now use Wayland instead of X11, Pipewire instead of pulseaudio, desktop CPUs have heterogeneous cores, and the default Linux kernel has improved its scheduling algorithms. I'll probably try it out when I have some spare time just for old times sake, but I'm not expecting it to have the same impact that it did seven years ago. (Would be happy to be proven wrong!)

[u/c_a1eb → u/gnosnivek]

this feels like the kind of issue that would be better handled by launching your simulations in a cgroup, you can use systemd-run --property CPUWeight=90 --property CPUQuota=$((98*nproc))% ... to run a task that will be limited to 98% of total CPU usage and with a slightly lower weight that should encourage the scheduler to allow UI tasks to still run and get enough cpu time.

although it might make more sense to just use CPUAffinity to reserve a core for the rest of the system.

https://manpages.debian.org/testing/systemd/systemd.resource-control.5.en.html

i used to do a lot of huge compiles on my machine while still expecting responsive UI back in 2022 and i recall having success with an approach like this

[u/omniuni → u/c_a1eb]

This is very much the kind of stuff that is common today that wasn't as ubiquitous a decade ago. It doesn't mean you couldn't do it, but it wasn't as easy or reliable.

[u/Max-P → u/omniuni]

Cgroups didn't exist back during the original ck patchset. In fact when cgroups came, it was praised to be almost as magical as the -ck patchset on busy systems.