Re: [PATCH] bufq_priocscan enhancement

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

thanks for working on this.

> Implementation
> ----------------------
> There used to be 2 queues and requests were inserted in right order to them 
> by 
> searching them from the start. I have simply removed the queues in favor of 
> rb trees, however the code is not very pretty because I needed to support 
> both cylinder and raw block number sort orders (a lot of code duplication), 
> maybe I can hack it around with some macros. Or maybe someone has a better 
> idea how to do it in an elegant fasion.
> 
> The other ugly thing which I am aware of, is that it will work incorrectly 
> (or 
> crash) if someday it becomes possible to change the sort order at runtime 
> (fortunately grepping the code shows it does not happen). Maybe I can add 
> some more assertions to catch it if it becomes true.

as far as i know nothing changes the sort order at runtime.  don't worry
about it.  parameter changes are rare events and should be done by creating
a brand new bufq and moving requests from the old one if necessary.
(but asssertions are good.)

we prefer sys/rbtree.h than sys/tree.h these days.
(i haven't checked the situation for 5.1, tho)
with sys/rbtree.h, you don't need to have the union because the type of
tree is always rb_tree_t.

> Maybe I can implement some other strategy which would be aware of processes 
> (as CFQ in Linux) and assign processes sort of timeslices for disk I/O to 
> avoid such starvation. It would require a change in bufq interface AFAIK 
> though. If we want to avoid the interface change, maybe at least something 
> like deadline strategy under Linux (assigning requests a deadline and 
> executing starving ones before any other).

unfortunately i don't think either cfq or deadline is possible without
interface changes.  please don't hesitate to change the interface. :-)

besides that, they probably need higher resolution timers than what we
currently have to perform better.

YAMAMOTO Takashi