Pluggable Disk Schedulers in GEOM

[R. B. Riddick]

--- lulf at stud.ntnu.no wrote:
> for I/O. Then I would extract out the default I/O scheduler and try out some
> other ways to schedule I/O. Also, I'm not sure how I would handle each
> schedulers way to organize the queue. One should allow for different types
> of bioq's for the schedulers since they may have different needs of
> organizing queues (like a heap maybe).
>
I would _guess_ for features like in TCQ (Tagged Command Queuing) or NCQ
(Native Command Queuing) the g_down thread is the wrong place, because: It
would need knowledge about the underlying GEOM device, so that it can determine
the correct moment to start a certain read request (currently g_down
(g_io_schedule_down in src/sys/geom/geom_io.c) sees most likely just one
request in its queue before it goes to sleep again, so that reordering this
single one request would make no sense; if one delays read request this might
lead to worse performance than before, because the disk handles simultaneous
read requests better).

For write requests this (TCQ/NCQ related scheduling) might be easier, because
they can be delayed and delivered back up (g_up) early (I did that in graid5).

A further enhancement might be the combination of requests (e.g. if they
overlap or if they (nearly) adjoin to each other), which could be done in
g_down, too (I do that in graid5, which leaded to a lot of bcopy-activity).

-Arne

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com