Re: Regarding dm-ioband tests

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
    ... It's similar to running out of CPU bandwidth, ... >> Whether it meets the spirit of the standard is debatable. ... > deterministic scheduling order, and a deterministic scheduling ... When Con and Ingo started floating scheduler proposals, ...
    (Linux-Kernel)
  • Re: posix threads, pthread_yeld
    ... Its use should be strongly discouraged because it is neither standard nor standardized. ... thread within the same process during the DRAFTS of the document that eventually became POSIX 1003.1c-1995. ... That is, pthread_yieldwas never standard, but it existed in drafts at least through something like draft 7 or 8. ... In any case, pthread_yieldneedn't do anything at all EXCEPT when your threads are using POSIX realtime scheduling policies on a uniprocessor. ...
    (comp.programming.threads)
  • Re: effect of sched_set{param|scheduler} on MT-process
    ... >Common laddies and gentlemen! ... >> | functions shall have no effect on their scheduling. ... PCS), and some threads in the same process be system contention scope ... Most of the rest of the prose in the standard are corallaries of SCS ...
    (comp.unix.programmer)
  • Progress in instruction scheduling
    ... standard compiler books, I got to know that many schedulers are based ... on "list scheduling" which seems to be the standard approach. ... last years concerning instruction scheduling leading to more advanced ...
    (comp.dsp)
  • Progress in instruction scheduling
    ... standard compiler books, I got to know that many schedulers are based ... on "list scheduling" which seems to be the standard approach. ... last years concerning instruction scheduling leading to more advanced ...
    (comp.arch.embedded)