On Thu, Nov 11, 2010 at 21:07, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: >> On 2010-11-10 21:03, Vivek Goyal wrote: >>> On Wed, Nov 10, 2010 at 01:26:21PM -0500, David Zeuthen wrote: >>>> On Wed, Nov 10, 2010 at 11:47 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: >>>>> From within the block layer in the kernel, it is difficult to >>>>> automatically detect the performance characteristics of the underlying >>>>> storage. ÂIt was suggested by Jens Axboe at LSF2010 that we write a udev >>>>> rule to tune the I/O scheduler properly for most cases. ÂThe basic >>>>> approach is to leave CFQ's default tunings alone for SATA disks. ÂFor >>>>> everything else, turn off slice idling and bump the quantum in order to >>>>> drive higher queue depths. ÂThis patch is an attempt to implement this. >>>>> >>>>> 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. ÂI look forward >>>>> to your comments. >>>> >>>> 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. >> >> That's the primary reason why I suggested doing this in user space. Plus >> we don't always know in the kernel, at least this provides an easier way >> to auto-tune things. > > Right, so given the above, is there still opposition to doing this in > udev? Not in general. Udev can do such things, that's what it's there for. It can do quirks, custom setups, and support tweaked configs that way. But it's usually not meant to set common defaults for every box. The last time we got into this business, and set timeouts for scsi devices from udev, we broke more recent kernels that did not like the specified values anymore, and we needed to remove all that in released versions, to be able to safely run newer kernels. And we've been told not to do such a thing in the future. And all what your rules are doing is to unconditionally apply kernel-internal knowledge to kernel devices -- which if you look at it from one step back -- is a bit weird. So I guess, this should be done from the multipath package, the dm setup, some 'tweak.rpm', ... I'm not sure, if we can do that for everybody from the main udev sources, for the same reasons the scsi timeout was wrong to do from udev. The time we added it, it seemed to be the right thing, but 2 years later it wasn't, because the kernel evolved, and we got into its way. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
