Bill Studenmund wrote:
> On Mon, Aug 21, 2006 at 04:21:27PM -0700, Matt Thomas wrote:
>> Bill Studenmund wrote:
>>> On Mon, Aug 21, 2006 at 04:46:50PM -0400, Thor Lancelot Simon wrote:
>>>> I cannot imagine how, in general, doing that could actually have any other
>>>> than a negative performance impact.
>>> Depends.
>>>
>>> If our congestion prediction model is accurate, then we can predict 
>>> congestion before we encounter it. Thus for a correct model, I believe 
>>> that there is _a_ value for _X_ that will work well.
>> I disagree.  X will vary on the "quality" of writes.  If you have lots of
>> sequential writes, the amount of them you can do will be higher than if you
>> lots of random writes.  So the threshold will vary.
> 
> Please feel free to dive in and help extend the algorithm to handle this. 
> You are right, but we have to start somewhere; it does little good to 
> argue about paint color before you've framed the walls. :-)
> 
> As a minor asside, I'd prefer keeping _X_ the same and just making 
> "poorer" writes cost more, with all costs being compared against the 
> constant _X_.
> 
> One problem, of course, is detecting sequential vs random disk i/o at the 
> levels where we make these measurements.

My proposal when Thor proposed the idea was to add jittered sleeps to
random writes.  As the average queue time for write i/o goes past a knee,
the system picks random writes and them complete "slower" by random amounts.

Upon further reflection, I'd probably be measuring average distribution of
i/o times for a process, and then when picking the amount to defer the
completions choose a value relative to the standard deviation; the larger
the standard deviation, the larger the percentage of the i/o time is used
to compute range of the completion deferral.  Good writes will be penalized
less than bad writes.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.