Anticipatory disk scheduling - soc 2008

[Matthew Dillon]

:Nirmal Thacker wrote:
:> I thought of exactly the same thing (except I was not sure where to
:> add this)since I assume that the scheduler which I write should be
:> accessbile as an interface (hence add an API) rather than plugging it
:> into the NATA driver. However this would require me to modify (would
:> it?) calls in the nata code - is this OK?
:
:Sure thing.  I think eventually all disk drivers which have latency due t=
:o=20
:seeks would use this API.
:
:>>    This would allow you to test your scheduler with a vkernel by also =
:having
:>>    the VKD driver call it (/usr/src/sys/dev/virtual/disk).
:>=20
:> Im not sure of what I understand about the vkernel. Is this a common
:> feature in BSD systems or only the DragonflyBSD? Could I have more
:> information (or hyperlinks) to this and how it is important or can
:> help me in testing my scheduler, as you mention above.
:
:This is D-d-d-dragonFly exlusive(-ive-ive-ive)!  Have a look at vkernel(7=
:).
:
:cheers
:   simon

    And if you really wanted to go whole-hog, create a really generic API
    that implements multiple disk schedulers and move the elevator algorithm
    into it as one of several schedulers, and your anticipatory algorithm
    as another scheduler.

    And if you wanted to get ultra-fancy you could implement disk-layer
    ioctl's to set the scheduler.  Ok, that might be going too far, but
    it's a cool idea!

    I suspect that there is a lot of room for experimentation in this area
    of research, not only elevator and anticipatory style schedulers but
    also schedulers which reorder reads to improve performance, or are more
    tag-friendly, and so on and so forth.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>