[lkml]   [2008]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [tbench regression fixes]: digging out smelly deadmen.
    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. is O(1), and falls
    apart too, I posted the numbers and full dbench output yesterday.


     \ /
      Last update: 2008-10-27 13:09    [W:0.020 / U:28.904 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site