| View previous topic :: View next topic |
| Author |
Message |
eMPee584
Apprentice
Joined: 01 Nov 2003
Posts: 152
Location: Aachen, Germany
|
 Posted: Wed Sep 17, 2008 7:35 pm Post subject: my stupid half-working CGROUPs daemon shell script |
 |
|
Hi there.
Now like many others on amd64 with a recent kernel, i was experiencing very discomforting interactivity issues with my 4400x2 3gb ram system that almost drove me mad. Since some time i wanted to make progress in even grokking the concept of control groups, but apart from the kernel patches and their documentation, googling did not turn much up. No guides, no tools, no gui. Well finally, yesterday i took the time and  RTFM (Documentation/cgroup.txt in the kernel dir). So I created a dir /mnt/cgroup, put
| Code: | | cgroup /mnt/cgroup cgroup rw,cpuacct,cpu |
in my fstab, created two subdirectories
| Code: | mkdir /mnt/cgroup/realtime
mkdir /mnt/cgroup/idle |
and set the cpushares with
| Code: | echo 10240 > /mnt/cgroup/realtime/cpu.shares
echo 2 > /mnt/cgroup/idle/cpu.shares |
.
Well, now how do the tasks i want to have in those groups end up there? No gui, no tool.. well i thought, go ahead script something. I created a simple stub /etc/init.d/auto-cgroup entry to start my daemon script /sbin/auto-cgroup.sh:
| Code: |
#!/bin/bash
CGROUP_PATH=/mnt/cgroup
# params (group, program, withChildren)
addToGroup () {
if [ -d $CGROUP_PATH/$1 ] && [ ! -z $2 ]
then
ppid=`ps -C $2 -o pid=`
if [ ! -z $ppid ]
then
echo $ppid > $CGROUP_PATH/$1/tasks
echo "group($1):program($2) - pid($ppid)" # debug output
if [ $3 ]
then
for pid in `ps --ppid $ppid -o pid=`; do
echo $pid > $CGROUP_PATH/$1/tasks
echo "group($1):child($2) -- pid($pid)" # debug output
done
fi
fi
fi
}
while [ true ]; do
realtime="vlc kwin"
idle="boinc_client paludis"
for program in $realtime; do
addToGroup 'realtime' $program
done
for program in $idle; do
addToGroup 'idle' $program true
done
sleep 2s;
done
|
This contains a lot of first-timeisms probably, but it seemed to work at first. But not really. It finds the process ids and puts them into the respective groups every 2 seconds, sure. But after a small time... well Do'H! know i can't reproduce the problem. It used to come up with errors while writing to the tasks file after some time but i changed the script a bit, now it seems to work, at least according to the output of
| Code: | | for group in realtime idle;do echo "$group:"; for pid in `cat /mnt/cgroup/$group/tasks`;do ps -p $pid --no-header; done;done |
However, it didn't have all that miracleous of an impact on my system responsiveness, and it is a bit hackish.. ain't there no better way? This surely is not a scalable solution.. comments appreciated.
_________________
"You cannot teach people anything. You can only help them discover it within themselves." --Galileo
expand your state of mind by not watching tv =)
- .... .. ... .-- --- .-. .-.. -.. .. ... .-- . .-.. .-.. .-- .. -.-. -.- . -..
|
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 3526
|
| Posted: Thu Sep 18, 2008 12:58 pm Post subject: |
|
|
Last I heard, the normal solution is to just turn off all of the group scheduling stuff. That's what I've done, though I've been hoping to see a good daemon emerge at some point.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
eMPee584
Apprentice
Joined: 01 Nov 2003
Posts: 152
Location: Aachen, Germany
|
| Posted: Thu Sep 18, 2008 4:26 pm Post subject: you must be kidding? |
|
|
finally, we have this ubercool feature allowing us to do awesome complex prioritizing wizardry which i spent many hours on tying to exploit... and you tell me it's unusable and i should turn it OFF??? WTF  *G********
so.. do i need to remove cgroups from my kernel configuration or just unmount the cgroup? because since the cfs scheduler was introduced (which iirc was when i enabled the cgroup feature without actually having a clue) i am experiencing stupid interactivity issues intensely getting on my nerves..
can you give me a citation for what you said? everywhere i looked i just perceived the d00d, this is k3wl st4ph message..
_________________
"You cannot teach people anything. You can only help them discover it within themselves." --Galileo
expand your state of mind by not watching tv =)
- .... .. ... .-- --- .-. .-.. -.. .. ... .-- . .-.. .-.. .-- .. -.-. -.- . -..
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3526
|
| Posted: Thu Sep 18, 2008 6:33 pm Post subject: |
|
|
The CFS is there, and can't be turned off. What I'm suggesting to turn off is Fair Group Scheduling. Look at it like they're adding a new wing onto the house. In this particular case, the basic plumbing is done, the drain is in the floor, and the water comes up and terminates at a cutoff valve. That's the kernel side.
Now it's up to someone else to bring in the toilet, install it on a wax ring, and pipe the water to the intake. That's the userspace side.
It's not usable until the toilet is installed, even if the plumbing is done. Beyond that since this is a new wing, and there is existing plumbing on the same lines, you really want to stuff a rag in the drain to keep the crud vapors where they belong. My "stuffed cloth" is:
| Code: | # CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set |
There have been preliminary stabs at daemons to make this work, and I figured yours was one of them. but so far there doesn't appear to be anything good enough for a good sit'n'read.
As for a reference, this was flying around the forums a few months back, when the first blush of CONFIG_GROUP_SCHED made it into the stable kernel, and CONFIG_CGROUPS didn't exist, yet. Here's one reference: https://forums.gentoo.org/viewtopic-t-659021-highlight-group+scheduler.html
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
eMPee584
Apprentice
Joined: 01 Nov 2003
Posts: 152
Location: Aachen, Germany
|
| Posted: Sat Oct 11, 2008 3:47 pm Post subject: following up... |
|
|
| depontius wrote: | | It's not usable until the toilet is installed, even if the plumbing is done. |
Yeah well that is not so clear from the documentation.. thx to your hints i turned it off now but with little improvement on VLC stream playing stability.. also i get <edit>EXTREMELY annoying multi-minute</edit> lock ups all the time but that might be related to my extreme compcache setting (2.5/3gb RAM for compcache, no hard disk swap), that i will research after rebooting into 2.6.27-rc9-git2 later on - right after another commercial break
_________________
"You cannot teach people anything. You can only help them discover it within themselves." --Galileo
expand your state of mind by not watching tv =)
- .... .. ... .-- --- .-. .-.. -.. .. ... .-- . .-.. .-.. .-- .. -.-. -.- . -..
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3526
|
| Posted: Mon Oct 13, 2008 1:09 pm Post subject: |
|
|
I get occasional stalls on my home machine, but from what I can tell those are related to having my $HOME on nfs, and running nfs client/server on 2.6.25 kernels. Those stalls tend to be in the 2-10 second range, not minutes. Does anything show up in the logs when you get your multi-minute stalls? I also have some lagging focus on my work machine, so with 2.6.25-gentoo-r8 I've decided to add the "latencyTop" kernel features, and I'll see what that has to say. But I fear that my focus lag is really because of my ancient dual-PIII-733 hardware, and the fact that the nVidia driver isn't all that hot for plain-old 2D. I'm also thinking of trying the Nouveau drivers to speed up my 2D response.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
eMPee584
Apprentice
Joined: 01 Nov 2003
Posts: 152
Location: Aachen, Germany
|
| Posted: Mon Dec 08, 2008 12:58 am Post subject: blame it on the OOM killer.. |
|
|
well recently i have not been running into this issue, which might well be to the fact that my KDE4 has not been starting up for weeks now and i settled with fluxbox and one instance of firefox instead of KDE and various konqueror instances PLUS firefox.
i really think this was an oom_killer problem.. i also added these settings to my /etc/sysctl.conf:
| Code: | vm.overcommit_memory = 2
vm.overcommit_ratio = 70
vm.oom_kill_allocating_task = 1
|
which makes the kernel not act stupid and allocate memory it won't be able to provide under suboptimal (real) circumstances etc.
_________________
"You cannot teach people anything. You can only help them discover it within themselves." --Galileo
expand your state of mind by not watching tv =)
- .... .. ... .-- --- .-. .-.. -.. .. ... .-- . .-.. .-.. .-- .. -.-. -.- . -..
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
