On Mon, Nov 15, 2010 at 15:57, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Fri, Nov 12, 2010 at 03:36:47PM +0100, Kay Sievers wrote: >> 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. > > Hi Kay, > > I can understand the issue of a rule being not valid anymore if kernel > evolves. But the question is what's wrong with that? Why can't we keep > on updating the udev rules as kernel and hardware evolves. Are they > supposed to be set in stone once a rule has been written? > > Even if we move the rule to some other user space package, then that > package will face the same issue of rule being not valid any more if > kernel evolves. So that will be equivalent just shifting the problem > from one user space package to other. > > To me key thing here is whether udev should try to set up some reasonable > IO scheduler defaults for system or not or it should be left entirely > to kernel. > > "Deadline" IO scheduler generally works very well with enterprise storage. > CFQ primarly cuts down seeks for very seeky media like SATA drive. Kernel > by default keeps CFQ as default for all the devices and we are trying to > improve out of the box experience for the user instead of imposing CFQ > on everybody and expecting them to change it later to deadline where > appropriate. > > Because rules are still not very clear yet and we are not sure how well > this notion of CFQ for SATA is going to play with everybody, to me it > still might not be a bad idea to initially write a udev rule and if > this works reasonably well or kernel evolves, we can modify the rule > accordingly. Udev can be the engine to change stuff on demand, but it should not ship *common defaults* which are only gathered from kernel information. If that's the goal, and it should be done for all systems, please change the kernel to that directly, and don't put that into udev. It would be a different picture if userspace would be involved in some sense, like persistently storing results of 'disk tests', or something similar, and applying calculated values based on these earlier results, to the actual disk when it is re-discovered. It would probably also involve permanent monitoring, and updating these values. Retrieving simple kernel values and re-apply them to the kernel does not make much sense in general, not for block devices, not for other subsystems, and things like that should not got into the udev repository for the reasons mentioned in the earlier mail. 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
