Subject: Re: Throttling IO Requests in NetBSD via Congestion Control
To: Bill Studenmund <firstname.lastname@example.org>
From: Matt Thomas <email@example.com>
Date: 08/21/2006 21:29:42
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.
>>> 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: firstname.lastname@example.org
3am Software Foundry www: http://3am-software.com/bio/matt/
Cupertino, CA disclaimer: I avow all knowledge of this message.