[lkml]   [2009]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[updated] BFS vs. mainline scheduler benchmarks and measurements

    * Ingo Molnar <> wrote:

    > OLTP performance (postgresql + sysbench)

    To everyone who might care about this, i've updated the sysbench
    results to latest -tip:

    This double checks the effects of the various interactivity fixlets
    in the scheduler tree (whose interactivity effects
    mentioned/documented in the various threads on lkml) in the
    throughput space too and they also improved sysbench performance.

    Con, i'd also like to thank you for raising general interest in
    scheduler latencies once more by posting the BFS patch. It gave us
    more bugreports upstream and gave us desktop users willing to test
    patches which in turn helps us improve the code. When users choose
    to suffer in silence that is never helpful.

    BFS isnt particularly strong in this graph - from having looked at
    the workload under BFS my impression was that this is primarily due
    to you having cut out much of the sched-domains SMP load-balancer
    code. BFS 'insta-balances' very agressively, which hurts cache
    affine workloads rather visibly.

    You might want to have a look at that design detail if you care -
    load-balancing is in significant parts orthogonal to the basic
    design of a fair scheduler.

    For example we kept much of the existing load-balancer when we went
    to CFS in v2.6.23 - the fairness engine and the load-balancer are in
    large parts independent units of code and can be improved/tweaked

    There's interactions, but the concepts are largely separate.



     \ /
      Last update: 2009-09-10 09:45    [W:0.022 / U:8.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site