Ric Wheeler wrote: > Jens Axboe wrote: >> On Thu, Jun 19 2008, 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. >>> >>> 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 disagree with this approach. For now, lets just add a queue flag that >> says the device doesn't have a seek penalty and let the io schedulers do >> what they need to avoid that (it'd be a one-liner change to cfq and as). >> There's more to io scheduling than just seek reduction, so this is the >> wrong direction to take imo. >> >> > Very true - you still will get a significant win by coalescing IO's (say > for example, to do larger, aligned writes to flash devices). > > ric > And to not let HUGE writers hug the machine. A scheduler ... -- 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
