The ~200 Line Linux Kernel Patch That Does Wonders

[zicada]

BS

did you even re-compile your kernel ?

when enabling the autogroup option and cgroups for CFQ - which you're asked for the responsibility "feels" much better

also: my apps seem to close and open noticably faster - it might be only 1-2 seconds less but it's noticable in my everyday workflow

Placebo, unless you open all those apps from a terminal, AND have a task running that tries to eat up all your resources. Why do people think this patch is some kinda magical thing ?

Which of the apps you're opening are attached to TTYs ?

I recommend actually reading the thread discussing this patch before you go around calling my prev. post BS.

[misGnomer]

Excellent points.

Ultimately the kernel is there to accommodate different user-space cases, with sane defaults, options and all.

The two sides of the whole (i.e us all) need to cooperate; and they do.

Here (the optional) systemd represents users-space tools for adjusting system/kernel behaviour "on-the-fly" and with higher level of granularity.

Still, the ability to configure kernel-space behaviour (at the time of compilation and without specific user-space tools) will be expected.

All the eyeballs are there so... bring on 2011! (the year when Linux... servers take over the desktop!)

Update:
After the fight Linus vs Lennart (kernel vs user) at the end Lennart implemented the same thing the patch does in systemd (check out latest commit).

If the requisite is :

The latency improves only by isolating tasks in containers (cgroups)

In think Systemd acheives this in the right way:

1. all is configurable (with pam-systemd you can choose whatever controller you like (cpu, memory, block by which every user isolate his tasks);
2. systemd knows better what is a session (the kernel doesn't even know it);
3. anytime, you can see what is going on (do a pstree on /sys/fs/cgroup)

[Obscene_CNN]

I don't know if anybody has seen this but its an alternative to the 200 line patch that does the same thing. Just add 4 lines to your bashrc and do two commands on the command line.

http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

benchmarks of both methods

http://lkml.org/lkml/2010/11/16/392

[purehg]

Excellent points.

Ultimately the kernel is there to accommodate different user-space cases, with sane defaults, options and all.

The two sides of the whole (i.e us all) need to cooperate; and they do.

Here (the optional) systemd represents users-space tools for adjusting system/kernel behaviour "on-the-fly" and with higher level of granularity.

Still, the ability to configure kernel-space behaviour (at the time of compilation and without specific user-space tools) will be expected.

All the eyeballs are there so... bring on 2011! (the year when Linux... servers take over the desktop!)

This patch is really not supposed to be there! Lennart gave a 6 line script that does exactly the same and Linus said Mike developed the patch the same way.

Linus' concern is that this behaviour is not default, but it should not be default if it is just a policy. I think that's the whole point those guys are arguing about. I do not think this patch is appropriate personally. Go with BFS. BFS rules.

[Ryushin]

Not necessarily. I've successfully applied the patch to a vanilla 2.6.36 kernel. The only thing i had to do was to correct two small errors.

If someone is interested, here is the patch for kernel-version 2.6.36 :

sched_automated_per_tty_task_groups_2.6.36.patch

Thank you for the patch. It applied cleanly and I'm compiling now.

[purehg]

I don't know if anybody has seen this but its an alternative to the 200 line patch that does the same thing. Just add 4 lines to your bashrc and do two commands on the command line.

http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html

benchmarks of both methods

http://lkml.org/lkml/2010/11/16/392

Exactly. I posted the same 2 pages back.

When you translate a 6 line script to a 200 line kernel patch, it suddenly doesn't seem exciting anymore does it.

[Obscene_CNN]

Just a thought,

Is there a way to use this patch to give an app that runs in a TTY priority over the GUI? In some cases people do have mission critical apps.

[djchester]

Update:
After the fight Linus vs Lennart (kernel vs user) at the end Lennart implemented the same thing the patch does in systemd (check out latest commit).

If the requisite is :

The latency improves only by isolating tasks in containers (cgroups)

In think Systemd acheives this in the right way:

1. all is configurable (with pam-systemd you can choose whatever controller you like (cpu, memory, block by which every user isolate his tasks);
2. systemd knows better what is a session (the kernel doesn't even know it);
3. anytime, you can see what is going on (do a pstree on /sys/fs/cgroup);

I would like to point out that this great work comes from the following history:

• Con Kolivas sd scheduler;
• Ingo Molnar cfs scheduler;
• Ingo introduce Paul Menage cgroups in cfs scheduler;
• Mike Galbraith in-kernel autogrouping based on cfs-cgroup scheduler;
• Lennart Pottering autogrouping in user-space (systemd);

This is a great story of success.
Thanks to all people involved

Marco

Thanks for summarizing it Marco.

I totally agree with the systemd solution and I am looking forward to testing it. Hopefully this will be availible in package updates for RHEL6(?).

It would be interesting if we could set a approximate date on the history bullets?

[bolzerrr]

can someone backport this patch to the lucid kernel 2.6.32-22 ?

[devsk]

This is a very stupid thread. You could do this with cgroups long ago (for cpu, disk and memory as well). All you need to do is to create wrappers for your favorite (or hated) programs to isolate their resource usage behavior. Read up on this:

http://broadcast.oreilly.com/2009/06/manage-your-performance-with-cgroups-and-projects.html

And yes, some people here are right. This is not going to magically speed up your program loads or make gcc compile your source faster (if at all, it will be a slow down in throughput: Ingo says its around 5% overhead).