lkml.org 
[lkml]   [2010]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2010-09-12 22:41    [W:0.388 / U:0.036 seconds]
©2003-2014 Jasper Spaans. Advertise on this site