Subject: Re: IO Congestion Control
To: Thor Lancelot Simon <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 09/11/2006 17:05:44
Content-Type: text/plain; charset=us-ascii
On Mon, Sep 11, 2006 at 11:43:24AM -0400, Thor Lancelot Simon wrote:
> On Mon, Sep 11, 2006 at 10:32:56AM -0500, Sumantra Kundu wrote:
> > Since no two IO devices are the same, this implies we need to have a
> > mechanism that is able to capture and understand the "capabilities",
> > "limitations", and "performance" of such a device at run time and make
> > such performance figures available to the UVM, before any sort of
> > device directed IO throttling could be initiated. To top it, writes
> > need not be of the same cost and can generally be thought of a
> > function of the disk seek time.
> I will repeat one last time my assertion that attempting to characterize
> the performance of disk devices is the wrong approach. Rather, a network-
> like congestion detection algorithm would be superior: one which prevents
> processes which frequently dirty pages when the request latency is
> increasing (or the queue length is growing) from dirtying further pages.
Please suggest an algorithm and implementation. The more detailed, the=20
Also, I think we will need more than one algorithm in the end. I can think=
of different cases, that will need different scheduling routines. So I=20
think there is benefit in Sumantra going ahead with what he proposes. It's=
not the end-all-be-all, and the project has already shown that doing=20
something then learning is a great approach; we will need multiple algos=20
in the end, so this can just be the first one.
My concern with "Network congestion algorithms" is that I don't see how=20
they map directly to this problem, and also I'm not certain that once they=
get mapped that they won't look like what we're describing above. I will=20
greatly appreciate concrete examples to the contrary.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----