Re: interactive task starvation

[Mike Galbraith <efault@gmx.de>]

On Wed, 2006-03-22 at 09:51 +1100, Peter Williams wrote:
> Mike Galbraith wrote:
> > On Tue, 2006-03-21 at 13:59 +0100, Willy Tarreau wrote:
> >>That would suit me perfectly. I think I would set them both to zero.
> >>It's not clear to me what workload they can help, it seems that they
> >>try to allow a sometimes unfair scheduling.
> > 
> > 
> > Correct.  Massively unfair scheduling is what interactivity requires.
> > 
> 
> Selective unfairness not massive unfairness is what's required.  The 
> hard part is automating the selectiveness especially when there are 
> three quite different types of task that need special treatment: 1) the 
> X server, 2) normal interactive tasks and 3) media streamers; each of 
> which has different behavioural characteristics.  A single mechanism 
> that classifies all of these as "interactive" will unfortunately catch a 
> lot of tasks that don't belong to any one of these types.

Yes, selective would be nice, but it's still massively unfair that is
required.  There is no criteria available for discrimination, so my
patches don't even try to classify, they only enforce the rules.  I
don't classify X as interactive, I merely provide a mechanism which
enables X to accumulate the cycles an interactive task needs to be able
to perform by actually _being_ interactive, by conforming to the
definition of sleep_avg.  Fortunately, it uses that mechanism.  I do
nothing more than trade stout rope for good behavior.  I anchor one end
to a boulder, the other to a task's neck.  The mechanism is agnostic.
The task determines whether it gets hung or not, and the user determines
how long the rope is.

	-Mike