On Thu, Sep 10, 2009 at 12:45:47PM +0900, Ryo Tsuruta wrote: > Hi Vivek, > > Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > In addition, > > > there are devices which doesn't use standard IO schedulers, and > > > dm-ioband can work on even such devices. > > > > This is a interesting use case. Few thoughts. > > > > - Can't io scheduling mechanism of these devices make use of elevator and > > elevator fair queuing interfaces to take advantage of io controlling > > mechanism. It should not be too difficult. Look at noop. It has > > just 131 lines of code and it now supports hierarchical io scheduling. > > > > This will come with request queue and its merging and plug/unplug > > mechanism. Is that an issue? > > > > - If not, then yes, for these corner cases, io scheduler based controller > > does not work as it is. > > I have a extreme fast SSD and its device driver provides its own > make_request_fn(). So the device driver intercepts IO requests and the > subsequent processes are done within it. IMHO, in those cases these SSD driver needs to hook into block layer's request queue mechanism if they need io controlling mechanism instead of we coming up a device mapper module. Think of it that if somebody needs CFQ like tasks classes and prio suported on these devices, should we also come up with another device mapper module "dm-cfq"? Jens, I am wondering if similiar concerns have popped in the past also for CFQ also? Somebody asking to support task prio and classes on devices which don't use standard IO scheduler? Thanks Vivek -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
