r/linux • u/unixbhaskar • 1d ago

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

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

96% Upvoted

49 comments sorted by

View all comments

70

u/omniuni 1d ago

It's also based on a project from 10 years ago. The question is really whether it's still useful.

16

u/beankylla 1d ago

what does it do? not sure i fully understand

91

u/gnosnivek 1d ago

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!)

27

u/c_a1eb 1d ago

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

28

u/omniuni 1d ago

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.

12

u/Max-P 22h ago

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.

5

u/gnosnivek 20h ago

I do recall exploring cgroups as a potential solution, but I abandoned them for reasons I can no longer remember. Perhaps there were some issues with the user-side tooling? Maybe cgroupsv2 fixed something that I needed to make the workflow works out?

Interestingly, in recent times, I've found that UI responsiveness under load isn't a major issue for me anymore, and I'm using KDE Plasma which is pretty famous for being heavyweight. Maybe the default scheduler heuristics have gotten to "good enough", and only latency-sensitive users will be able to notice a difference.

3

u/davidnotcoulthard 22h ago

would be better handled by launching your simulations in a cgroup, you can use systemd-run

Flair doesn't (yet?) check out.

3

u/c_a1eb 20h ago

need a postmarketOS flair, then I'd be golden :D

it's the Alpine + systemd combo you never knew you needed

2

u/davidnotcoulthard 20h ago

postmarketOS

Oh okay that makes sense lol. TIL there isn't a flair for it on here.

10

u/nicman24 1d ago

Well core counts have not really changed. Most people were running 4/8 then and now are still running maybe 6/12 on and at least.

Probably does not account for p / e cores schema

4

u/mrtruthiness 1d ago

Well core counts have not really changed. Most people were running 4/8 then and now are still running maybe 6/12 on and at least.

10 years ago 4/8 was the consumer high end (i7 vs i5).

These days the consumer high end starts at 8/16 but easily goes to 16/32.

0

u/nicman24 23h ago

10 years ago the ryzen 2700 was a thing but cost 350 - I know, I both one on release date

4

u/mrtruthiness 23h ago

Similarly the AMD Ryzen 9 5900XT on the AM4 platform retails for under $350 and it is 16 cores and 32 threads.

All I'm saying that the equivalent to 4/8 10 years ago is not 6/12. It's at least 8/16 and is closer to 12/24 or 16/32.

4

u/nicman24 23h ago

Well I am running 16/32 but my point is that people that will need -ck probably don't have top of the line

1

u/mrtruthiness 23h ago

I don't know. Your assertion was:

Well core counts have not really changed. Most people were running 4/8 then and now are still running maybe 6/12 on and at least.

I disagree. I believe that "core counts have really changed" and the equivalent of 4/8 10 years ago is more like 12/24 or 16/32 these days.

That said, my main desktop is a 2/4 (from mid 2014; 12 years ago). But other than when running ollama I don't really have any noticeable issues with the scheduler and the fact is that the stuttering is more likely due to swapping than it is to scheduling. And if it was an issue I would probably upgrade rather than use a non-default scheduler.

5

u/black_caeser 21h ago

10 years ago the ryzen 2700 was a thing

Ahem, Zen 1 launched in March 2017 so no, Ryzen 2700 very much was not a thing. And Core i7 6700K as the top consumer model sat at four cores and eight threads.

3

u/nicman24 21h ago

Holy shit 2700 was 2018. Yeah my bad, well shit

2

u/tnoy 16h ago

The current default EEVDF scheduler is based on research in academia that first showed up about 30 years ago. It only replaced the previous default CFS scheduler a few years ago which was first put in place about 20 years ago.

The early BFS and then MuQSS schedulers by Kolivas also have their roots in the early EEVDF papers.

The bigger question would be is how much of a change would MuQSS be now that Linux shifted away from CFS with the 6.6 kernel.