Re: interactive task starvation

[Mike Galbraith <efault@gmx.de>]

On Tue, 2006-03-21 at 07:47 +0100, Willy Tarreau wrote:
> Hi Mike,

Greetings!

> On Mon, Mar 20, 2006 at 08:09:13AM +0100, Mike Galbraith wrote:
> > real    0m0.512s
> > user    0m0.112s
> > sys     0m0.138s
> > 
> > ...while running with the same apache loadavg of over 10, and tunables
> > set to server mode (0,0).
...

> Very good job !
> I told Grant in a private email that I felt confident the problem would
> quickly be solved now that someone familiar with the scheduler could
> reliably reproduce it. Your numbers look excellent, I'm willing to test.
> Could you remind us what kernel and what patches we need to apply to
> try the same, please ?

You bet.  I'm most happy to have someone try it other than me :)

Apply the patches from the attached tarball in the obvious order to
2.6.16-rc6-mm2.  As delivered, it's knobs are set up for a desktop box.
For a server, you'll probably want maximum starvation resistance, so
echo 0 > /proc/sys/kernel/grace_g1 and grace_g2.  This will set the time
a task can exceed expected cpu (based upon sleep_avg) to zero seconds,
ie immediate throttling upon detection.  It will also disable some
interactivity specific code in the scheduler.

If you want to fiddle with the knobs, grace_g1 is the number of CPU
seconds a new task is authorized to run completely free of any
intervention... startup in a desktop environment.  grace_g2 is the
amount of CPU seconds a well behaved task can store for later usage.
With the throttling patch, an interactive task must earn the right to
exceed expected cpu by performing within expectations.  The longer the
task behaves, the more 'good carma' it earns.  This allows interactive
tasks to do a burst of activity, but the user determines how long that
burst==starvation is authorized.  Tasks with just use as much cpu as
they can get run headlong into the throttle.

	-Mike

Attachment: throttle-V23-2.6.16-rc6-mm2.tar.gz
Description: application/compressed-tar