Re: NEW_BUFQ_STRATEGY
Thor Lancelot Simon <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.performance,gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Dec 05, 2003 at 08:23:12PM +0900, YAMAMOTO Takashi wrote: > hi, > > > On Dec 3, 2003, at 5:38 PM, YAMAMOTO Takashi wrote: > > > > > because synchronous writes, which nfsd often requests, easily suffer? > > > i guess explicitly distinguishing sync/async requests like the > > > attached diff makes it better. > > > > Cool, though I guess BUFQ_READ_PRIO should no longer be the name of the > > queueing discipline... perhaps just BUFQ_PRIO? > > i think it's better to leave BUFQ_READ_PRIO as-is and create a new one > for people who like benchmarks... :) Your patch basically turns the policy into the same one SGI uses, and I think it's a much more reasonable default than pure "read priority"; there are problems with read priority delaying synchronous writes dating back at least 10 years in the literature. One thing I'm not so sure about is using a FCFS queue for the "time sensitive" requests. I think that the average latency for requests from that queue is probably significantly increased by using FCFS rather than the increasing-block-number sort, because we lose the benefit of readahead, which will be particularly severe if the queues are long. The sort seems particularly likely to be beneficial given the rather large number of requests we take from the queues in a "burst" and the consequent likelihood that we'd get a lot of track cache hits. Thor