--DfnuYBTqzt7sVGu3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Aug 28, 2006 at 03:41:14PM -0400, Greg Troxel wrote:
> For example, it isn't clear to me that penalizing
> writers is even the right thing

That's part of my concern, too.

There are applications where it's surely the wrong thing; my PVR
springs immediately to mind.  I want to record N concurrent streams to
disk, and this represents a predictable fairly constant write rate.
If this rate is higher than the hardware can support, I need better
hardware.  The only way software and kernel can really help is if
there are competing readers, and (apart from indirect metadata reads
generated by writes) I want to penalise the readers, not the writers.

Even aside from such purpose-specific circumstances, there are other
factors.  Write cache is enabled by default on most commodity
hardware, which hides the cost of writes amongst reads and idle time
... until the cache is full.  Meanwhile, without TCQ/NCQ, reads are
synchronous. So if we want to detect impending congestion for writes,
other than at the big step when the cache is full, we probably need to
look at read latencies.

That's not to say this work won't be very useful to explore and
quantify the problem, just that we shouldn't leap to conclusions about
the solution.  Bill (as mentor) seems pretty clear on that point too,
which is great.

--
Dan.

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

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

iD8DBQFE85hOEAVxvV4N66cRAv15AJ9U9Z/3E32TOe8+Ceq7njVSo4FTCwCfcQO3
abMCbpheIFh0wSJn6taIscU=
=0CGL
-----END PGP SIGNATURE-----

--DfnuYBTqzt7sVGu3--