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
