Alternative To The 200 Lines Kernel Patch

[nschubach]

So what's up with his warning about 64-bit?

[mister_playboy]

So what's up with his warning about 64-bit?

The warning only applies to the patched kernels he has linked to... it's not a warning about following the terminal commands procedure.

The patched kernel comes with this new scheduling turned on by default... apparently the functionality has been present in the kernel for a while, but inactive.

[libssd]

Given the context described in one of the references:

One of the problems commonly talked about in our forums and elsewhere is the poor responsiveness of the Linux desktop when dealing with significant disk activity on systems where there is insufficient RAM or the disks are slow.

I'm not sure this change will make much difference, since I have 2 gb of RAM and a SSD, but I decided to give it a try anyway. Before I added more RAM, I did notice that as soon as swap started being used, performance fell off a cliff.

After making a fresh, restorable system backup, I made the changes and rebooted. No surprises, and no error messages. As Joeb454 says, it seems to be a little faster on scrolling, but that could just as easily be my imagination. But, a netbook with an N450 processor needs every bit of help it can get.

Now, can somebody explain in ENGLISH exactly what these changes do? I am in awe of someone like Lennart Poettering, who can rethink a 200+ line kernel patch as 5 lines of code in rc.local, but I'd like a little better understanding of how this mod actually works. The explanation here: http://www.omgubuntu.co.uk/2010/11/l...-to-new-patch/ is gibberish to me:

Each task’s signal struct contains an inherited pointer to a refcounted autogroup struct containing a task group pointer, the default for all tasks pointing to the init_task_group. When a task calls __proc_set_tty(), the process wide reference to the default group is dropped, a new task group is created, and the process is moved into the new task group. Children thereafter inherit this task group, and increase its refcount. On exit, a reference to the current task group is dropped when the last reference to each signal struct is dropped. The task group is destroyed when the last signal struct referencing it is freed. At runqueue selection time, If a task has no cgroup assignment, its current autogroup is used.

[libssd]

One more question: when a new kernel comes along, should this be backed out?

[marl30]

Anybody else who was still getting an error, someone left this comment on the blog with an update that fixed the error.

Slightly improved version of the cgroup_clean script:

#!/bin/sh
if [ "$1" != "/user" ]; then
rmdir /dev/cgroup/cpu/$1
fi

[handy]

I'm using this solution, which I think is an improvement to Lennart's script:

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

P.S. I'm running it on Arch, as is, so I expect that you will still have to use the Ubuntu specific modifications to get around the Ubuntu error message.

[udippel]

Question: is there a need to install cgroup-bin to actually make the 'hack' work??
I should think so in the first place, but could be wrong as well ...

Any expert?

[Stigmata13]

I think I'll just wait until Canonical themselves release a patch via apt-get upgrade. As much as I love playing around with my system, its pretty stable as it is and I don't see much point in going through the risk of causing problems for myself in the future.

[Locke_99GS]

I've been running the 200 patch on a vanilla 2.6.37-rc2 kernel for about a week now on two machines. The difference is most noticeable on the older crappier machine, which is also where it's most appreciated.

Doing it outside the kernel is a kludge.

[handy]

...
Doing it outside the kernel is a kludge.

Why is it a kludge?

It is so quick & easy, compared to to playing with kernels.

Initially, the only reason it is going into the kernel is to cater to the ever growing group of users that don't want to edit config files & such, which by the way, has been shown on the lkml site to give faster performance than the kernel patch. (kludge? )


The other thing, which is already happening (since PATCH v4), is that there are more changes in-store for us before (& after) the patch makes it into the stable kernel.

How many of these will come to us via the easy file editing option remains to be seen.