lkml.org 
[lkml]   [2008]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [tbench regression fixes]: digging out smelly deadmen.
    Date
    On Tuesday 28 October 2008 05:33, Ingo Molnar wrote:
    > * Alan Cox <alan@lxorguk.ukuu.org.uk> 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).

    You can get good dbench results come from dbench on tmpfs, which
    exercises the vm vfs scheduler etc without IO or filesystems.


    \
     
     \ /
      Last update: 2008-10-29 11:03    [W:0.028 / U:0.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site