[ale] faster linux

[Pat Regan]

On Thu, 25 Nov 2010 13:58:54 -0500
arxaaron <arxaaron at gmail.com> wrote:

> Thanks Brian - as usual - for a great bit of concise information.
> 
> > http://lwn.net/SubscriberLink/415740/3c25d44d948ecd44/
> 
> After getting an understanding from the article of how the
> mechanism works, I tend to agree with Galbraith that this
> feature belongs in user space (aka his 4 line bash patch)
> with the improved implementation of per session group
> scheduling down the road.

I agree that it belongs in user space.

I would imagine the biggest reason Linus would want it in the kernel is
so that it will spread to end users faster if it is in the kernel.

> It just seems more functional and flexible to keep process
> prioritizing in the user's hands regardless of whether you
> are scheduling from a list of all processes (aka running
> "make" with "-j##") or equitably distributed groups of
> processes (aka real time media delivery group vs. time
> flexible tasks).

I've never bothered to research the available user space tools to
control cgroups.  There's a decent set of automated cgroup management
tools in the cgroup-bin package in debian/ubuntu.

The daemon matches usernames and executable names and automatically
dumps the processes into the configured cgroup.

I set up a cgroup that I called "background" with a limit of 1/4th the
default cpu shares.  I'm automatically dumping things like make and
handbrake jobs into that cgroup.

For my purposes this will work quite well but it doesn't give quite the
same results as the kernel modification or the 4 line bash script...

With the bash script...  If you run a 'make -j64' in one terminal and a
'make -j4' in another terminal then both terminals will get about 50%
of the cpu.  The advantage, in my opinion, over the bash script is that
if other processes need cpu then the two make jobs combined won't
exceed 25%.

I am definitely going to play around with this a bit more.

Pat