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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
