If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
The ~200 Line Linux Kernel Patch That Does Wonders
Welcome back, Linux! Prior to this patch, on 2.6.36 a simple rsync of some multi-gigabyte files over a 6-disk raid on a core i7 with 12GB ram would take the desktop down. Audio stutters, compiz windows fading out due to delays, and unable to start a tomcat server in eclipse due to the default 45 second startup timeout.
Post patch on 2.6.37 results doing the same rsync as before, compiling the kernel with a -j30, playing audio, and launching tomcat from eclipse and no stutters or nasty delays!!!! The load hit about 40, and the system kept running without any extreme delays!
Those wondering if the patch helps with the io issues, I'd have to say yes. The only kernel change I did from the 2.6.36 was to enable the automatic process group scheduling. You could see the throughput go up and down during the rsync. This sure beats having to worry about ionice and bandwidth limiting the rsync process just to avoid desktop issues.
Thanks for the simple yet extremely helpful patch.
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.
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:
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).