Alternative to 200 lines kernel patch, /sys/fs/cgroup/cpu missing
 

Hi !

I tried this :
http://www.webupd8.org/2010/11/alter...nel-patch.html

Compiled my kernel with all cgroups options, but /sys/fs/cgroup/cpu, and i can't mkdir it.

Any idea ?

I`m wondering what these entries in .bashrc mean? And if it works why hasn`t it been used before? It looks that linux kernel got big and complicated and nobody understands it as a whole if someone tries to patch a kernel against something solvable with bash setup.

Well it seems it's a trick nobody though about. Linux is ahead it's own developers ^^.

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

Seems the bash script stuff was used to test a feature of the kernel.

The patch is the permanent solution.

All this cgroup stuff is clever, but can't you just run your heavy process under nice if you want to keep working on your desktop while it runs? That's what I do.

Of course you can, but how many users are actually using this way? I think most normal users are even not aware of nice. The kernel patch will automate this.

nice works well but requires users to do things manually.

Compiled and installed libcgroup.
Created /cgroup/cpu/

Did :
mount -t cgroup cgroup /cgroup/cpu/ -o cpu
mkdir -m 0777 /cgroup/cpu/user/

Here's my .bashrc :
if [ "$PS1" ] ; then
mkdir -m 0700 /cgroup/cpu/user/$$
echo $$ > /cgroup/cpu/user/$$/tasks
fi

But it changes nothing !

On other distros, seems there's a cgconfig service to start...

The risk is that it could have side effects for those who do want to control this themselves using nice.

I think I'll go google up some information. I'm curious how this new automated cgroup patch will interact with manually niced processes.

As long as it's a kernel option you can disable I don't see it as problem, but it's a solution for a problem I don't have so I can't get excited about it.


edit: Con Kolivas has blogged on the subject of the new patch. Interesting read.

Cross link :
http://www.linuxquestions.org/questi...groups-844712/

Yay ! Con Kolivas breaks all our dreams ^^.
The "schedtool -D -e make -j64 blahblah" seems very interesting.

The patch (posted by Mike Galbraith - clean 2.6.36): http://marc.info/?l=linux-kernel&m=129011104931337&w=2

Only that? Any other interaction? libcgroup anyone??

It works !!!

Just remember to CLOSE the terminal when testing, because it keeps the .bashrc settings, even if you modify it (of course)!

In the slashdot discussion on the subject it was mentioned several times that this will only work for applications started from a tty, or a single bash session. This means, as Con Kolivas wrote, that the "normal" GUI apps started from the desktop (e.g. via krunner or the kde menu) will not see a difference (as all of them will be grouped together), and that in any case the window manager may be modified to do something similar to what the scripts do.

The reply from Kolivas is however a little naive. Many people reported better performance, but he is mainly attacking the patch basing his reply on what Linus wrote.

my useless opinion: Considering how explorer.exe usually just freezes the whole windows xp interface in the office pc, I have always felt that Linux does a good job handling load. In some distributions the desktop feels sluggish, while in others it does not (personal experience: kde on OpenSuSE 10.3 x86_64 was a pain compared to Slackware 12.2 on the same machine), so the system setup matters. Desktop effects sometimes slow things, or makes things look slow: I don't really like to wait for a menu to show up just because it is fading in.

I will be happy anyway to have a way to avoid my backup (to an external USB drive, run by root usually in tty6) making the desktop slow, which is something I do see on my system with any distro I've tried.

Or do source ~/.bashrc

@Linux and Ian,

When firing up the thing, I got:
'cgroup path is (null)'? <-- ok?

Would you mind sharing your configs for libcgroup and kernel (cgroup)? =]