--JP+T4n/bALQSJXh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 28, 2006 at 02:21:22PM +0200, TlorD wrote:
> Bill Studenmund wrote:
> > On Mon, Aug 21, 2006 at 04:46:59PM -0400, Kurt J. Lidl wrote:
> >> On Mon, Aug 21, 2006 at 01:35:03PM -0700, Bill Studenmund wrote:
> >> As for the slowdown that is seen, you might just be forcing more
> >> head I/O on the platter, which will quickly dominate any other sources
> >> of slowness.
> >=20
> > I don't think so. I can certainly see extra seek action contributing to=
=20
> > reads not catching up as much as writes are restrained (i.e. I could se=
e=20
> > this contributing to a 20% slowdown in writes turning into less than a =
20%=20
> > increase in reads). But we're seeing fewer reads overall.
>=20
> Just a random thought: what if the induced sleep is interfering with the
> I/O scheduler/disk buffers, thus causing more seeks?

Turns out it's not. It's an issue with the page daemon not flushing pages=
=20
fast enough.

> Let me try to clarify: good reads and writes are big, sequential ones,
> sent one after the other to the disk which then moves the head as little
> as possible. If, by adding sleeps, writes are sent few per batch, they
> can't be coalesced well and will thus be transformed into bad (small)
> writes, which would skyrocket the seek number thus lowering the read
> rate. I think.

I don't think the effect will be so bad as to skyrocket the write seeks.=20
The _count_ over time may well go up, but the whole idea is that they are=
=20
spread out in time.

Take care,

Bill

--JP+T4n/bALQSJXh8
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD4DBQFE8yZ2Wz+3JHUci9cRArXWAJ4/EPmRi3Y/2thJRXL/GEJ5HEAYKQCUD1Ou
ERS/xtpWENgj1ZrAkenndA==
=0+zS
-----END PGP SIGNATURE-----

--JP+T4n/bALQSJXh8--