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

Mathieu Desnoyers
2010-09-12T20:39:28Z

* Peter Zijlstra (peterz@infradead.org) wrote:
> On Sun, 2010-09-12 at 11:06 +0200, Peter Zijlstra wrote:
> > * is slice length, + is period length
> >
> > Patch (sched_latency = 10, sched_min_gran = 10/3)
> >
> >
> > 30 | +
> > |
> > |
> > | +
> > |
> > |
> > |
> > |
> > |
> > |
> > 20 |
> > |
> > |
> > |
> > |
> > |
> > |
> > |
> > |
> > |
> > 10 | * + + + + + + +
> > |
> > |
> > |
> > |
> > | *
> > |
> > | * * * * * * * *
> > | * *
> > | * *
> > 0 +---------------------------------------------------------
> > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
>
>
> Vertical is time , horz is nr_running.
>
>
> Note how things fall of a cliff when nr_running goes from 8 to 9. Andrew
> usually kicks people in the teeth for phase change behaviour.

Please refer to my other email asking why your sched_latency = 10 rather than
what I see in sched_fair.c:

unsigned int sysctl_sched_latency = 6000000ULL;

I really might have missed something important there. Is this value recomputed
dynamically somewhere ?

Thanks,

Mathieu

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.