Re: [tbench regression fixes]: digging out smelly deadmen.

Ingo Molnar
2008-10-27T11:28:38Z

* 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