Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running

[Mike Galbraith <efault@gmx.de>]

On Mon, 2010-09-13 at 08:41 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> 
> > On Sun, 2010-09-12 at 14:16 -0400, Mathieu Desnoyers wrote:
> 
> > > Or am I missing your point ?
> > 
> > Yes and no.  I'm pondering the parent, but by the same token, the 
> > vfork child shouldn't be penalized either.
> > 
> > Does your latency go down drastically if you turn START_DEBIT off? 
> > Seems like it should.  Perhaps START_DEBIT should not start a task 
> > further right than rightmost.  I've done that before.
> > 
> > maximum latency: 19221.5 µs
> > average latency: 5159.0 µs
> > missed timer events: 0
> > 
> > maximum latency: 43901.0 µs
> > average latency: 8430.1 µs
> > missed timer events: 0
> > 
> > Turning it off here cut latency roughly in half (i've piddled vfork 
> > though, but not completely).  Limiting child placement to no further 
> > right than rightmost should help quite a bit.
> 
> Very interesting observation. Mathieu, mind testing Mike's suggestion 
> with wakeup-latency.c?

I'm sure it will.  I think the problem is that light thread forks, the
child takes vruntime hit, so the parent's lag isn't _useful_.  It may
preempt, but the work it's trying to get done is delayed massively
unfairly.

btw, setting parent's lag to that of the child on parent wakeup for the
vfork case seems to work fine, kbuild no longer gets the advantage it
would vs static load if START_DEBIT were disabled.  That leaves what to
do with plain old fork/clone though.  Leaving START_DEBIT in place for
fork/clone vs a fair vfork load blows chunks, as does running a forky
load vs some static load without START_DEBIT.

Sticky wicket.  We need a better fork fairness gizmo.

	-Mike