Messages in this thread | | | Subject | Re: [tbench regression fixes]: digging out smelly deadmen. | From | Mike Galbraith <> | Date | Mon, 27 Oct 2008 13:06:11 +0100 |
| |
On Mon, 2008-10-27 at 11:33 +0000, Alan Cox wrote: > > 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.
Doesn't seem to be scheduler/fairness. 2.6.22.19 is O(1), and falls apart too, I posted the numbers and full dbench output yesterday.
-Mike
| |