Tag Archives: performance

Miracle patch out-performed by four lines of bash

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

Lennart said:

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.


Con Kolivas posts his thoughts on the new ~200 line kernel patch

Con Kolivas (of SD/BFS fame) has posted his thoughts on the new ~200 line “miracle” kernel patch. It’s an interesting read.

In short, he had already implemented something like this in a 10 line patch to his BFS scheduler, but he dropped them because it introduced regressions.

Those following the development of the patches for interactivity at massive load, I have COMPLETELY DROPPED them as they introduce regressions at normal workloads, and I cannot under any circumstances approve changes to improve behaviour at ridiculous workloads which affect regular ones. I still see precisely zero point at optimising for absurd workloads. Proving how many un-niced jobs you can throw at your kernel compiles is not a measure of one’s prowess. It is just a mindless test.

He goes on to say:

Again, I can’t for the life of me see why you’d optimise for make -j64 on a quad core machine. It is one workload, unique to people who compile all the time, but done in a way you wouldn’t normally do it anyway. It is not going to magically make anything else better. If for some god-forsaken reason you wanted to do that, you could already do that with nice, or even better, by running it SCHED_IDLEPRIO.

Perhaps this patch really helps the existing CFS implementation, but it’s still lacking when compared to BFS. Maybe it is a step in the wrong direction, but perhaps some improvement like this is better than none at all? It might be the catalyst needed to improve the kernel further. I never could understand why we couldn’t have more than one CPU scheduler in the kernel (like we do for block I/O).

Anyway, this is all quite interesting!


~200 line miracle Linux patch

There’s been lots of criticism from certain camps that Linus and the kernel developers don’t care enough about the desktop and that it has too much focus on big iron. There certainly have been (and continue to be) issues with Linux on the desktop, in terms of performance. Lately there has been a push to improve it, perhaps driven by the need to have Linux running well on small devices like Android and MeeGo.

Or perhaps it stems from much further back. We all remember anaesthetist Con Kolivas’s kernel patches (Kororaa used -ck, back in the day) and schedulers which improved desktop performance a whole lot, but in the end he was shunned, and then quit development. Linus wasn’t convinced, and Ingo Moln├ír (the CPU scheduler maintainer) then wrote a new scheduler which was more like Con’s (ironically named, Completely Fair Scheduler). Although he quit, two years later Con was still using Linux and couldn’t stand the desktop responsiveness any more, so he created a new scheduler, BFS (with no intention if getting it into the mainstream kernel).

Why is this important? Well now someone else is having a go. The small 200 line patch by Mike Galbrait has such a tremendous impact that even Linus can’t argue with the result.

If you want to see it in action, Phoronix has an article about the patch along with some videos showing the dramatic difference.

“Tests done by Mike show the maximum latency dropping by over ten times and the average latency of the desktop by about 60 times.”

With this patch, the desktop (running GNOME) can smoothly play the Ogg 1080p version of Big Buck Bunny and glxgears at the same time, while scrolling up and down a Firefox window and.. wait for it.. performing a kernel compile with make -j64.

xkcd Supported Features
xkcd, “Supported Features”

I don’t think that this will be merged until 2.6.38 as the 2.6.37 window has already closed.