[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH] bufq_priocscan enhancement
> On Wed, 8 Jun 2011 01:37:59 +0000 (UTC)
> yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
>> 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. :-)
> What kind of interface changes would that require?
cfq would require kick-on-timer-expire which is iirc impossible with
the current interface.
i don't remember what prevented deadline. probably my memory is just wrong.
>> besides that, they probably need higher resolution timers than what we
>> currently have to perform better.
>> YAMAMOTO Takashi
> NetBSD - Simplicity is prerequisite for reliability
Main Index |
Thread Index |