--LwW0XdcUbUexiWVK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > 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.
>=20
> 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
better.

Also, I think we will need more than one algorithm in the end. I can think=
=20
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=
=20
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=
=20
get mapped that they won't look like what we're describing above. I will=20
greatly appreciate concrete examples to the contrary.

Take care,

Bill

--LwW0XdcUbUexiWVK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFBfnXWz+3JHUci9cRAn8gAJ9Fk9+EJQItY0g7RuaDmemBIY5bZgCeJMsH
rnIE4pIftTQ4tIJahzriLC4=
=LYBB
-----END PGP SIGNATURE-----

--LwW0XdcUbUexiWVK--