[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] bufq_priocscan enhancement
thanks for working on this.
> There used to be 2 queues and requests were inserted in right order to them
> 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
> 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.
Main Index |
Thread Index |