Messages in this thread | | | Subject | Re: fio mmap randread 64k more than 40% regression with 2.6.33-rc1 | From | "Zhang, Yanmin" <> | Date | Mon, 18 Jan 2010 11:06:38 +0800 |
| |
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.
| |