[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.

    * 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. [...]

    i've actually implemented that about a decade ago: i've tracked down
    what makes dbench tick, i've implemented the kernel heuristics for it
    to make dbench scale linearly with the number of clients - just to be
    shot down by Linus about my utter rubbish approach ;-)

    > [...] 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 best dbench results come from systems that have enough RAM to
    cache the full working set, and a filesystem intelligent enough to not
    insert bogus IO serialization cycles (ext3 is not such a filesystem).

    The moment there's real IO it becomes harder to analyze but the same
    basic behavior remains: the more unfair the IO scheduler, the "better"
    dbench results we get.


     \ /
      Last update: 2008-10-27 19:35    [W:0.033 / U:15.060 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site