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

* Ingo Molnar <mingo@elte.hu> wrote:

> OLTP performance (postgresql + sysbench)
> http://redhat.com/~mingo/misc/bfs-vs-tip-oltp.jpg

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

http://redhat.com/~mingo/misc/bfs-vs-tip-oltp-v2.jpg

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
separately.

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

Thanks,

Ingo


\
 
 \ /
  Last update: 2009-09-10 09:45    [W:0.763 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site