Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755926Ab0DVPx7 (ORCPT ); Thu, 22 Apr 2010 11:53:59 -0400 Received: from cantor.suse.de ([195.135.220.2]:51322 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755322Ab0DVPx5 (ORCPT ); Thu, 22 Apr 2010 11:53:57 -0400 Date: Thu, 22 Apr 2010 17:53:59 +0200 From: Jan Kara To: Miklos Szeredi Cc: Corrado Zoccolo , Jens Axboe , linux-kernel , Jan Kara , Suresh Jayaraman Subject: Re: CFQ read performance regression Message-ID: <20100422155358.GE5805@quack.suse.cz> References: <1271420878.24780.145.camel@tucsk.pomaz.szeredi.hu> <1271677562.24780.184.camel@tucsk.pomaz.szeredi.hu> <1271856324.24780.285.camel@tucsk.pomaz.szeredi.hu> <1271865911.24780.292.camel@tucsk.pomaz.szeredi.hu> <1271931809.24780.387.camel@tucsk.pomaz.szeredi.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1271931809.24780.387.camel@tucsk.pomaz.szeredi.hu> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1607 Lines: 37 On Thu 22-04-10 12:23:29, Miklos Szeredi wrote: > > > > > > This is on a vanilla 2.6.34-rc4 kernel with two tunables modified: > > > > > > read_ahead_kb=512 > > > low_latency=0 (for CFQ) > > You should get much better throughput by setting > > /sys/block/_your_disk_/queue/iosched/slice_idle to 0, or > > /sys/block/_your_disk_/queue/rotational to 0. > > slice_idle=0 definitely helps. rotational=0 seems to help on 2.6.34-rc > but not on 2.6.32. > > As far as I understand setting slice_idle to zero is just a workaround > to make cfq look at all the other queues instead of serving one > exclusively for a long time. Yes, basically it disables idling (i.e., waiting whether a thread sends more IO so that we can get better IO locality). > I have very little understanding of I/O scheduling but my idea of what's > really needed here is to realize that one queue is not able to saturate > the device and there's a large backlog of requests on other queues that > are waiting to be served. Is something like that implementable? I see a problem with defining "saturate the device" - but maybe we could measure something like "completed requests / sec" and try autotuning slice_idle to maximize this value (hopefully the utility function should be concave so we can just use "local optimization"). Honza -- Jan Kara SUSE Labs, CR -- 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/