On Thu, 2008-06-19 at 10:03 -0600, Matthew Wilcox wrote: > Use the noop elevator by default for drives that do not spin > > [Not for applying] > > SSDs do not benefit from the elevator. It just wastes precious CPU cycles. > By selecting the noop elevator by default, we can shave a few microseconds > off each IO. > > I've brazenly stolen sd_vpd_inquiry from mkp's patch here: > > http://marc.info/?l=linux-scsi&m=121264354724277&w=2 > > No need to have two copies of that ... but this will conflict with his code. > > On to the self-criticism: > > I don't intend the final version of this patch to include a printk for > the RPM or even a printk to say we switched IO elevator. I think we're > too verbose in SCSI as it is. > > I think there's an opportunity to improve sd_vpd_inquiry() to remove > some of the duplicate code between sd_set_elevator() and sd_block_limits, > but it's not terribly important. and actually ses.c as well. > The switching of the elevators isn't particularly nice. I assume that > elevator_init("noop") cannot fail, which isn't true. It would be nice > to use the #if 0 block instead, but that causes a null ptr dereference > inside sysfs -- I suspect something isn't set up correctly. I'm really not very keen on this patch, since it's implementing elevator policy from sd which is a bit of a layering violation (and a policy should be in userspace one). What's wrong with doing this entirely from udev (it already issues the vpd's today, that's how it gets the id from page 0x83 ... it could easily look at 0xb1 and set the elevator using /sys/block/<>/queue/scheduler)?. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
