hi, > On Wed, 8 Jun 2011 01:37:59 +0000 (UTC) > y...@mwd.biglobe.ne.jp (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
