lkml.org 
[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Subject[patchlet] Re: Epic regression in throughput since v2.6.23
    From
    Date
    On Wed, 2009-09-16 at 23:18 +0000, Serge Belyshev wrote:
    > Ingo Molnar <mingo@elte.hu> writes:
    >
    > > Ok, i think we've got a handle on that finally - mind checking latest
    > > -tip?
    >
    > Kernel build benchmark:
    > http://img11.imageshack.us/img11/4544/makej20090916.png
    >
    > I have also repeated video encode benchmarks described here:
    > http://article.gmane.org/gmane.linux.kernel/889444
    >
    > "x264 --preset ultrafast":
    > http://img11.imageshack.us/img11/9020/ultrafast20090916.png
    >
    > "x264 --preset medium":
    > http://img11.imageshack.us/img11/7729/medium20090916.png

    Pre-ramble..
    Most of the performance differences I've examined in all these CFS vs
    BFS threads boil down to fair scheduler vs unfair scheduler. If you
    favor hogs, naturally, hogs getting more bandwidth perform better than
    hogs getting their fair share. That's wonderful for hogs, somewhat less
    than wonderful for their competition. That fairness is not necessarily
    the best thing for throughput is well known. If you've got a single
    dissimilar task load running alone, favoring hogs may perform better..
    or not. What about mixed loads though? Is the throughput of frequent
    switchers less important than hog throughput?

    Moving right along..

    That x264 thing uncovered an interesting issue within CFS. That load is
    a frequent clone() customer, and when it has to compete against a not so
    fork/clone happy load, it suffers mightily. Even when running solo, ie
    only competing against it's own siblings, IFF sleeper fairness is
    enabled, the pain of thread startup latency is quite visible. With
    concurrent loads, it is agonizingly painful.

    concurrent load test
    tbench 8 vs
    x264 --preset ultrafast --no-scenecut --sync-lookahead 0 --qp 20 -o /dev/null --threads 8 soccer_4cif.y4m

    (i can turn knobs and get whatever numbers i want, including
    outperforming bfs, concurrent or solo.. not the point)

    START_DEBIT
    encoded 600 frames, 44.29 fps, 22096.60 kb/s
    encoded 600 frames, 43.59 fps, 22096.60 kb/s
    encoded 600 frames, 43.78 fps, 22096.60 kb/s
    encoded 600 frames, 43.77 fps, 22096.60 kb/s
    encoded 600 frames, 45.67 fps, 22096.60 kb/s

    8 1068214 672.35 MB/sec execute 57 sec
    8 1083785 672.16 MB/sec execute 58 sec
    8 1099188 672.18 MB/sec execute 59 sec
    8 1114626 672.00 MB/sec cleanup 60 sec
    8 1114626 671.96 MB/sec cleanup 60 sec

    NO_START_DEBIT
    encoded 600 frames, 123.19 fps, 22096.60 kb/s
    encoded 600 frames, 123.85 fps, 22096.60 kb/s
    encoded 600 frames, 120.05 fps, 22096.60 kb/s
    encoded 600 frames, 123.43 fps, 22096.60 kb/s
    encoded 600 frames, 121.27 fps, 22096.60 kb/s

    8 848135 533.79 MB/sec execute 57 sec
    8 860829 534.08 MB/sec execute 58 sec
    8 872840 533.74 MB/sec execute 59 sec
    8 885036 533.66 MB/sec cleanup 60 sec
    8 885036 533.64 MB/sec cleanup 60 sec

    2.6.31-bfs221-smp
    encoded 600 frames, 169.00 fps, 22096.60 kb/s
    encoded 600 frames, 163.85 fps, 22096.60 kb/s
    encoded 600 frames, 161.00 fps, 22096.60 kb/s
    encoded 600 frames, 155.57 fps, 22096.60 kb/s
    encoded 600 frames, 162.01 fps, 22096.60 kb/s

    8 458328 287.67 MB/sec execute 57 sec
    8 464442 288.68 MB/sec execute 58 sec
    8 471129 288.71 MB/sec execute 59 sec
    8 477643 288.61 MB/sec cleanup 60 sec
    8 477643 288.60 MB/sec cleanup 60 sec

    patchlet:

    sched: disable START_DEBIT.

    START_DEBIT induces unfairness to loads which fork/clone frequently when they
    must compete against loads which do not.


    Signed-off-by: Mike Galbraith <efault@gmx.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    LKML-Reference: <new-submission>

    kernel/sched_features.h | 2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)

    diff --git a/kernel/sched_features.h b/kernel/sched_features.h
    index d5059fd..2fc94a0 100644
    --- a/kernel/sched_features.h
    +++ b/kernel/sched_features.h
    @@ -23,7 +23,7 @@ SCHED_FEAT(NORMALIZED_SLEEPER, 0)
    * Place new tasks ahead so that they do not starve already running
    * tasks
    */
    -SCHED_FEAT(START_DEBIT, 1)
    +SCHED_FEAT(START_DEBIT, 0)

    /*
    * Should wakeups try to preempt running tasks.



    \
     
     \ /
      Last update: 2009-09-17 06:59    [W:0.038 / U:30.468 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site