From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755292AbZDOB1Y (ORCPT ); Tue, 14 Apr 2009 21:27:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752690AbZDOB1J (ORCPT ); Tue, 14 Apr 2009 21:27:09 -0400 Received: from mga09.intel.com ([134.134.136.24]:60464 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752288AbZDOB1I (ORCPT ); Tue, 14 Apr 2009 21:27:08 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,188,1239001200"; d="scan'208";a="403202568" Subject: Re: tiobench read 50% regression with 2.6.30-rc1 From: "Zhang, Yanmin" To: Jens Axboe Cc: LKML In-Reply-To: <20090414121431.GH5178@kernel.dk> References: <1239265763.2567.769.camel@ymzhang> <20090409095706.GD5178@kernel.dk> <1239330541.2567.779.camel@ymzhang> <20090414121431.GH5178@kernel.dk> Content-Type: text/plain Date: Wed, 15 Apr 2009 09:27:41 +0800 Message-Id: <1239758861.2567.813.camel@ymzhang> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-2.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2009-04-14 at 14:14 +0200, Jens Axboe wrote: > On Fri, Apr 10 2009, Zhang, Yanmin wrote: > > On Thu, 2009-04-09 at 11:57 +0200, Jens Axboe wrote: > > > On Thu, Apr 09 2009, Zhang, Yanmin wrote: > > > > Comparing with 2.6.29's result, tiobench (read) has about 50% regression > > > > with 2.6.30-rc1 on all my machines. Bisect down to below patch. > > > > > > > > b029195dda0129b427c6e579a3bb3ae752da3a93 is first bad commit > > > > commit b029195dda0129b427c6e579a3bb3ae752da3a93 > > > > Author: Jens Axboe > > > > Date: Tue Apr 7 11:38:31 2009 +0200 > > > > > > It's not a huge surprise that we regressed there. I'll get this fixed up > > > next week. Can you I talk you into trying to change the 'quantum' sysfs > > > variable for the drive? It's in /sys/block/xxx/queue/iosched where xxx > > > is your drive(s). It's set to 4, if you could try progressively larger > > > settings and retest, that would help get things started. > > I tried 4,8,16,64,128 and didn't find result difference. > > Can you try with this patch? The new patch does fix it. > > diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c > index a4809de..66f00e5 100644 > --- a/block/cfq-iosched.c > +++ b/block/cfq-iosched.c > @@ -1905,10 +1905,17 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq, > * Remember that we saw a request from this process, but > * don't start queuing just yet. Otherwise we risk seeing lots > * of tiny requests, because we disrupt the normal plugging > - * and merging. > + * and merging. If the request is already larger than a single > + * page, let it rip immediately. For that case we assume that > + * merging is already done. > */ > - if (cfq_cfqq_wait_request(cfqq)) > + if (cfq_cfqq_wait_request(cfqq)) { > + if (blk_rq_bytes(rq) > PAGE_CACHE_SIZE) { > + del_timer(&cfqd->idle_slice_timer); > + blk_start_queueing(cfqd->queue); > + } > cfq_mark_cfqq_must_dispatch(cfqq); > + } > } else if (cfq_should_preempt(cfqd, cfqq, rq)) { > /* > * not the active queue - expire current slice if it is >