Messages in this thread |  | | | Date | Wed, 29 Mar 2006 09:21:25 +0200 | | From | Jens Axboe <> | | Subject | Re: Block I/O Schedulers: Can they be made selectable/device? @runtime? |
On Wed, Mar 29 2006, Tejun Heo wrote: > Linda Walsh wrote: > >Is it still the case that block I/O schedulers (AS, CFQ, etc.) > >are only selectable at boot time? > > > >How difficult would it be to allow multiple, concurrent I/O > >schedulers running on different block devices? > > > >How close is the kernel to "being there"? I.e. if someone has a > >"regular" hard disk and a high-end solid state disk, can > >Linux allow whichever algorithm is best for the hardware? > >(or applications if they are run on separate block devices)? > > > > Hello, Linda, Jens. > > Actually, I've been thinking about related stuff for sometime. e.g. It > doesn't make much sense to use any scheduler other than noop for SSDs > and it also doesn't make much sense to plug requests for milliseconds to > such devices. So, what I'm currently thinking is... > > * Give LLDD a chance to say that it doesn't need fancy scheduling.
Something I've been meaning to do for ages as well. I figure the simplest way is to define a simple set of profiles, ala
enum { BLK_QUEUE_TYPE_HD, BLK_QUEUE_TYPE_SS, BLK_QUEUE_TYPE_CDROM, }; Make BLK_QUEUE_TYPE_HD the default setting, and then let setting of this look something ala:
q = blk_init_queue(rfn, lock); blk_set_queue_type(q, BLK_QUEUE_TYPE_SS); ...
and be done with it.
> * Automagically tune plugging time. We can maintain running average of > request turn-around time and use fraction of it to plug the device. This > should be give good enough merging behavior while not adding excessive > delay to seek time.
Sounds like too much work for little (or zero) benefit. The current heuristics are a little rough, and if you can show a tangible benefit from actually looking/calculating this stuff, then we can talk :-)
> * Don't leave device devices with queue depth > 1 idle. For queued > devices, we can push the first request fast such that the head moves to > proximity of what would probably follow. So, don't plug the first > request, plug from the second.
Trade off, if the next io is mergable it will still be a loss. But generally I like the idea!
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |