lkml.org 
[lkml]   [2008]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tbench regression fixes]: digging out smelly deadmen.

* Jiri Kosina <jkosina@suse.cz> wrote:

> Ok, so another important datapoint:
>
> with c1e4fe711a4 (just before CFS has been merged for 2.6.23), the dbench
> throughput measures
>
> 187.7 MB/s
>
> in our testing conditions (default config).
>
> With c31f2e8a42c4 (just after CFS has been merged for 2.6.23), the
> throughput measured by dbench is
>
> 82.3 MB/s
>
> This is the huge drop we have been looking for. After this, the
> performance was still going down gradually, up to ~45 MS/ we are
> measuring for 2.6.27. But the biggest drop (more than 50%) points
> directly to CFS merge.

that is a well-known property of dbench: it rewards unfairness in IO,
memory management and scheduling.

The way to get the best possible dbench numbers in CPU-bound dbench
runs, you have to throw away the scheduler completely, and do this
instead:

- first execute all requests of client 1
- then execute all requests of client 2
....
- execute all requests of client N

the moment the clients are allowed to overlap, the moment their requests
are executed more fairly, the dbench numbers drop.

Ingo


\
 
 \ /
  Last update: 2008-10-27 12:31    [W:0.118 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site