Messages in this thread | | | Date | Mon, 27 Oct 2008 12:27:50 +0100 | From | Ingo Molnar <> | Subject | Re: [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
| |