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.038 / U:60.148 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site