>From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
>To: Bill Studenmund <wrstuden@netbsd.org>
>CC: tech-kern@netbsd.org
>Subject: Re: I/O priorities Date: Fri, 21 Jun 2002 10:30:42 -0700
>
>In message 
><Pine.NEB.4.33.0206201044020.23822-100000@vespasia.home-net.internetc
> >I think that an i/o scheduler is the long-term solution to this problem.
> >It won't make 1.6 (it's WAY too late for that), but it's what we should
> >do.
>
>I think we need to go back to basics.  Exactly what is the acutal
>problem, here?

Here is my oversimplistic analysis:
The original poster said the behaviour was only noticeable in 1.6, which has 
UBC and not in 1.5.2 which does not. Since BOTH of these releases use the 
SAME disk scheduling algorithm (yes?), the problem is not with CSCAN vs. 
elevator vs. whatever disk scheduling algorithm. Major difference: 1.5.2 has 
a FIXED size buffer and a FIXED sized cache while UBC has a variable size 
combined scheme (yes?). Perhaps in 1.5.2 the FIXED sizes provide some 
predefined means of limiting I/O requests, while in 1.6 the variable size 
has lead to the overlooking of a new mechanism for limiting I/O requests 
(which must be determined dynamically at run time depending on load etc.).

I think the problem is one of limiting resource requests as pointed out in 
another post:

Stephen J. Dovich wrote:
>I think it's time to back up to first principles, and at the same
>time dredge up some old BSD history from another area.
[...]
>The underlying problem is that of apportioning each consumer a
>"fair" share of some resource.  For process scheduling, that resource
>is the processor across time. For I/O, the resource is device/bus
>bandwidth. BSD has had decent bandwidth management facilities for
>well over a decade.  Van Jacobsen and Mike Karels made the fundamental
>advance in dealing with detecting and responding to network congestion
>by identifying algorithms which converged on the fair-share allocation
>of network bandwidth.
>
>What we are looking at here is I/O congestion.  With a means of
>determining the available bandwidth, detecting channel saturation,
>and a means of throttling the requestors, there is no reason why
>TCP congestion avoidance algorithms can't contribute to effective
>management of I/O bandwidth.
>
>The real challenge is mapping those techniques onto the I/O problem.
>We don't have virtual circuits with window sizes to manipulate. But
>I am certain that a little clever engineering can provide the
>needed hooks. The main hurdle as I see it is adapting the method
>in such a way as to be able to throttle down to fair-share under
>congestion, and keep the algorithm cost low enough to not be a
>problem when not in a congested state.
>
>To speak more directly to Greywolf's query, I/O scheduling needs
>to limit the arrival rate from processes that exceed their fair
>share of the available device/bus bandwidth, for some suitable
>value of "fair" (as amended by priority/administrative policy).
>If we simply try to order the incoming requests to address the
>problem, I fear that all that happens it to move the problem
>to another workload pattern. The only real solution is to quench
>the arrival rate at the source, and tie that to adequate metrics
>of available bandwith and channel consumption. Using write time
>as a surrogate for those metrics is not sufficiently accurate or
>effective.
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.