Subject: Re: NEW_BUFQ_STRATEGY
To: None <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 12/05/2003 10:18:51
On Fri, Dec 05, 2003 at 08:23:12PM +0900, YAMAMOTO Takashi wrote:
> > 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.