DragonFly kernel List (threaded) for 2008-05
Re: Anticipatory disk scheduling - soc 2008
: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=
:seeks would use this API.
:>> This would allow you to test your scheduler with a vkernel by also =
:>> the VKD driver call it (/usr/src/sys/dev/virtual/disk).
:> 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=
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.