Quote:
Originally Posted by linus72
being an amateur, am I right in assuming I needed libcgroup with an autogroup patched kernel or no?
|
I don't believe so. My understanding is that libcgroup contains functions that allow you/or programs to control cgroups from userspace. the kernel autogrouping patch
is something that when enabled will automatically put processes into individual cgroups based on their session-id and as such doesn't have anything to do with libcgroup.
Quote:
Originally Posted by linus72
am I even right in thinking thiss patch is making things smoother/better??
|
It looks very situational.
Lets say you have an application program running (something interactive like firefox). and you then start a build with make -j 19.
You now have 20 programs running with equal priority. Firefox will get 5% (1/20th) of a share of the total cpu and each of the make jobs will also get 5% (I'm oversimplifying here as all the other processes in the system will still be getting their share and firefox will have more than a single process itself, but for sake of clarity lets pretend that those 20 processes are the only ones in the system). What's also important to remember though is that X itself is a process and will also need it's fair allocation of cpu time, and if that gets starved then every X program it serves will also suffer.
What the CONFIG_SCHED_AUTOGROUP thing will do is that instead of 20 process getting equal time, what will happen is that firefox will get 50% of the CPU and the 19 make processes will share the other 50%, so they'll get ~ 2.5% of overall cpu each.
Now, if you were running without the CONFIG_SCHED_AUTOGROUP but you chose to run "nice make -j 19 ...." then firefox would already be running at a higher priority than the 19 make jobs and in theory might even get higher than a 50% share if it needs it and the 19 make processes would get an equal share of whatever is left over.
Until this stuff matures and we can see it in operation I don't know whether this will be good or bad and how this will all interplay on a particular system with a particular workload is anyone's guess. My belief is that people don't make enough use of (re)nice as it is, and if they did there wouldn't be as much fuss over this new feature.
if you want to see what processes are going to be autogrouped into a cgroup (and competing with each other for cpu time) on your system then you can run this:
Code:
#!/bin/sh
# list all processes in sessions
for session in $( ps hax -o sess | grep -v " 0" | sort | uniq )
do
echo "Session: $session -------------------------------------"
ps -f -s $session
done
The results don't look unreasonable to me, though there's some room for improvement. Judicious use of 'setsid' might improve matters further.
