From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivek Goyal Date: Wed, 10 Nov 2010 20:03:38 +0000 Subject: Re: [patch|rfc] add support for I/O scheduler tuning Message-Id: <20101110200338.GA32733@redhat.com> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On Wed, Nov 10, 2010 at 01:26:21PM -0500, David Zeuthen wrote: > Hi, >=20 > On Wed, Nov 10, 2010 at 11:47 AM, Jeff Moyer wrote: > > Hi, > > > > From within the block layer in the kernel, it is difficult to > > automatically detect the performance characteristics of the underlying > > storage. =A0It was suggested by Jens Axboe at LSF2010 that we write a u= dev > > rule to tune the I/O scheduler properly for most cases. =A0The basic > > approach is to leave CFQ's default tunings alone for SATA disks. =A0For > > everything else, turn off slice idling and bump the quantum in order to > > drive higher queue depths. =A0This patch is an attempt to implement thi= s. > > > > I've tested it in a variety of configurations: > > - cciss devices > > - sata disks > > - sata ssds > > - enterprise storage (single path) > > - enterprise storage (multi-path) > > - multiple paths to a sata disk (yes, you can actually do that!) > > > > The tuning works as expected in all of those scenarios. =A0I look forwa= rd > > to your comments. >=20 > This looks useful, but I really think the kernel driver creating the > block device should choose/change the defaults for the created block > device - it seems really backwards to do this in user-space as an > afterthought. I think it just becomes little easier to implement in user space so that if things don't work as expected, somebody can easily disable the rules or somebody can easily refine the rule further to better suite their needs instead of driver hardcoding this decision. Thanks Vivek