[lkml]   [2010]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running
    On Sat, Sep 11, 2010 at 1:45 PM, Peter Zijlstra <> wrote:
    > On Sat, 2010-09-11 at 22:36 +0200, Peter Zijlstra wrote:
    >> But if you want us to change the scheduler to be more latency sensitive
    >> and trade in throughput for other benchmarks, we can do that.
    > Really, just say "latency trumps throughput" and we'll make it so.

    Nothing is ever that black-and-white.

    But latency really _is_ important. And it's often overlooked, because
    few benchmarks actually test it. So when somebody sends you actual
    measured latency numbers, you shouldn't be so cavalier. And you
    shouldn't say "trumps throughput", since it's clearly a matter of
    balancing, and quite frankly, Mathieu's patch does seem to try to
    balance things.

    As mentioned, it does seem to make tons of conceptual sense to take
    the number of running threads into account for the whole scheduling
    granularity decision. After all, we already do that for the other
    important numbers (the scheduling period and time slice).

    So to me it looks like you're just being negative, without actually
    looking at the patch and giving it some fair thought. That's what I'm
    objecting to.


     \ /
      Last update: 2010-09-11 22:55    [W:0.022 / U:5.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site