lkml.org 
[lkml]   [2010]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: fio mmap randread 64k more than 40% regression with 2.6.33-rc1
    From
    Date
    On Sat, 2010-01-16 at 17:27 +0100, Corrado Zoccolo wrote:
    > Hi Yanmin
    > On Mon, Jan 4, 2010 at 7:28 PM, Corrado Zoccolo <czoccolo@gmail.com> wrote:
    > > Hi Yanmin,
    > >> When low_latency=1, we get the biggest number with kernel 2.6.32.
    > >> Comparing with low_latency=0's result, the prior one is about 4% better.
    > > Ok, so 2.6.33 + corrado (with low_latency =0) is comparable with
    > > fastest 2.6.32, so we can consider the first part of the problem
    > > solved.
    > >
    > I think we can return now to your full script with queue merging.
    > I'm wondering if (in arm_slice_timer):
    > - if (cfqq->dispatched)
    > + if (cfqq->dispatched || (cfqq->new_cfqq && rq_in_driver(cfqd)))
    > return;
    > gives the same improvement you were experiencing just reverting to rq_in_driver.
    I did a quick testing against 2.6.33-rc1. With the new method, fio mmap randread 46k
    has about 20% improvement. With just checking rq_in_driver(cfqd), it has
    about 33% improvement.


    >
    > We saw that cfqq->dispatched worked fine when there was no queue
    > merging happening, so it must be something concerning merging,
    > probably dispatched is not accurate when we set up for a merging, but
    > the merging was not yet done.




    \
     
     \ /
      Last update: 2010-01-18 04:07    [W:0.023 / U:117.976 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site