[ale] faster linux

[Michael H. Warfield]

On Thu, 2010-11-25 at 22:18 -0500, Pat Regan wrote: 
> 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.

And on the gripping hand...  I would argue that it needs to be in both
and more.  The kernel patch does NOT preclude doing this in user space.
What it does is set a minimal functionality of support if you do
nothing.  This will be of benefit to many.  I would argue that the bash
patch is not sufficient, as well.  I want this done in things like
FireFox startup and Evolution and several other applications that could
benefit (most especially FF) from the isolation.  /usr/bin/firefox is
nothing more than a launcher script.  Why do we not incorportate this
into launcher scripts so things like FF can not cripple our machines
because of some moron's javascript that eats all your resources like
Audrey (little shop of horrors)?

Linus is right.  It deserves to be in the kernel.  But it's simply not
the only place it should be in.  It sets a floor.  A minimum value.  But
it also sets a paradigm to implement elsewhere as well in addition to...
The bash patch is also a good start...  But only a start.  Namespaces
and cgroups are a wonderfully rich facility on which to do all sorts of
isolation and virtualization (look at LXC).  This whole debate about
this or that is nothing more than a tempest in a teapot.  DO BOTH!

> > 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
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20101126/9f5eea2f/attachment.bin