Well it’s nothing if not interesting. The ~200 line “miracle” patch promises a huge improvement in desktop responsiveness, but Lennart Poettering (from Red Hat) has replied to Linus’ praising comments with 4 lines of bash which out-perform it, on the current vanilla kernel. (And by the way, Lennart seems to agree with Con Kolivas about this patch, in that make -j is not a valid desktop use case.)
Binding something like this to TTYs is just backwards. No graphical
session has a TTY attached anymore. And there might be multiple TTYs
used in the same session.
I really wonder why logic like this should live in kernel space at all,
since a) the kernel has no real notion of a session, except audit and b)
this is policy and as soon as people have this kind of group then they
probably want other kind of autogrouping as well for the other
controllers, which hence means userspace is a better, and configurable
place for this.
To which Linus then replied:
Numbers talk, bullshit walks.
The numbers have been quoted. The clear interactive behavior has been seen.
And you’re just full of bullshit.
Come back when you have something working and with numbers and better
interactive performance. Until then, nobody cares.
So, Lennart replied with his something better, 4 lines of bash:
Here’s my super-complex patch btw, to achieve exactly the same thing
from userspace without involving any kernel or systemd patching and
kernel-side logic. Simply edit your own ~/.bashrc and add this to the end:
if [ "$PS1" ] ; then
mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
Then, as the superuser do this:
mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
mkdir -m 0777 /sys/fs/cgroup/cpu/user
Done. Same effect. However: not crazy.
Of course the debate raged on because Linus thinks it’s stupid to make people have to set this up in userspace, and Lennart disagrees. Despite all this, finally everyone is at least acknowledging these issues and looking into them! Excellent.
Lol, great article. Let the flame wars begin.
Seriously though, the trouble with performance is it’s always VERY usage model dependent. If you make a scheduler change because you’re concerned about make -j 64 on a kernel build, that’s a very specialized usage model. Makes me wonder why they don’t create a dynamic scheduler which reconfigures itself basesd on current workload.
Precisely 🙂 Which is what Con Kolivas and Lennart have been saying, but it seems Linus disagrees. I’m just so happy that this is finally being discussed!
Recompiling the kernel in secure mode would have make the garbage collector to reasing the memory block in the correct way and we all be drinking beer now. Whoever does not believe this is the correct answer is a nazi.
linus has always been a bit of a dick.
I can never really understand anyone’s tolerance of Linus’ behaviour/language towards others. I think it should be hats off to Lennart for not replying in kind and actually standing his ground, proving Linus incorrect that all Lennart was doing was bs.
BTW, it’s always nice to see your writing.
Take Care and Be Well,
Yes it is interesting.. but then I guess that’s been helpful in the success of Linux. In a way you need some bastard up the top to keep things in line, otherwise someone soft would be accepting all sorts of code. Not that it’s an excuse for his behaviour at all, I think you can be tough, but not nasty. Unfortunately, Linus tends to lean towards the nasty side from time to time, but at least it makes for great Quotes down the road.
Yeah, I used to be interested in kernel-level development. Eventually it became clear that the options were (a) go work for a company making proprietary kernels, (b) hack on Linux and put up with Linus’ caustic personality, or (c) work on some other free kernel (like HURD) that was never going to even hit version 1.0.
Today I think all kernels are still kind of lousy, but not yet lousy enough for me to want to jump in and do something about it. Fortunately there are other areas of computer science that have interesting work, free software, and nice people. 🙂
You know what is a valid use case? Spawning hundreds of MP3Gain processes. I do this whenever I re-adjust my library. Once I do this, it locks the system.
We need this patch.