Messages in this thread |  | | Date | Sun, 12 Sep 2010 16:39:25 -0400 | | From | Mathieu Desnoyers <> | | Subject | Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running |
| |
* 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. http://www.efficios.com
|  |