Re: [PATCH] bufq_priocscan enhancement

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

hi,

> On Wed,  8 Jun 2011 01:37:59 +0000 (UTC)
> yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
> 
>> 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. :-)
> 
> 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.

YAMAMOTO Takashi

> 
>> besides that, they probably need higher resolution timers than what we
>> currently have to perform better.
>> 
>> YAMAMOTO Takashi
> 
> 
> -- 
> NetBSD - Simplicity is prerequisite for reliability