Messages in this thread | | | Date | Mon, 27 Oct 2008 11:33:06 +0000 | From | Alan Cox <> | Subject | Re: [tbench regression fixes]: digging out smelly deadmen. |
| |
> 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
Rubbish. If you do that you'll not get enough I/O in parallel to schedule the disk well (not that most of our I/O schedulers are doing the job well, and the vm writeback threads then mess it up and the lack of Arjans ioprio fixes then totally screw you) </rant>
> the moment the clients are allowed to overlap, the moment their requests > are executed more fairly, the dbench numbers drop.
Fairness isn't everything. Dbench is a fairly good tool for studying some real world workloads. If your fairness hurts throughput that much maybe your scheduler algorithm is just plain *wrong* as it isn't adapting to workload at all well.
Alan
| |