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.085 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site