Messages in this thread |  | | | From | Jeff Moyer <> | | Subject | Re: fio mmap randread 64k more than 40% regression with 2.6.33-rc1 | | Date | Tue, 19 Jan 2010 15:42:56 -0500 |
| |
Corrado Zoccolo <czoccolo@gmail.com> writes:
> On Mon, Jan 18, 2010 at 4:06 AM, Zhang, Yanmin > <yanmin_zhang@linux.intel.com> wrote: >> 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. >> > Jeff, do you have an idea why in arm_slice_timer, checking > rq_in_driver instead of cfqq->dispatched gives so much improvement in > presence of queue merging, while it doesn't have noticeable effect > when there are no merges?
It's tough to say. Is there any chance I could get some blktrace data for the run?
Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |