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

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:
> > On Mon, Aug 21, 2006 at 03:28:40PM -0400, Steven M. Bellovin wrote:
> > > I don't have an explanation for your results (though I wonder if
> > > metadata-related reads are part of the explanation), but I have serio=
us
> > > qualms about making processes sleep.  In the limiting case, that sets
> > > an upper bound on output rate, regardless of other demand.  Have you
> > > explored lowering scheduling priority instead?  That would allow other
> > > processes (which would generate read requests) to make more requeasts.
> >=20
> > As one of the mentors for this project, I think changing scheduling
> > priority can/should be investigated after the SoC project completes.
> >=20
> > I think there are a number of things to look into, like how to apply ba=
ck=20
> > pressure, and different ways to estimate congestion/decide when we shou=
ld=20
> > apply back pressure. I have a feeling we may well come up with a number=
 of=20
> > different things to try.
>=20
> Well, one of the other ways you can apply back-pressure to the writers
> is not to have the write() call complete as fast as you can dump
> data to the disk buffers.  Ie, just make write() stall until the
> appropriate time.  You don't have to fool with making the process sleep
> artificially this way.

Making write() stall is what this method is basically doing. :-) Making=20
write stall is making the process (or thread actually) sleep.

> 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.

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 see=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.

> I'd also like to know if the write-cache was turned on in the drive,
> and what attempt was made to keep the filesystems uniform across
> the various tests.  Many of the filesystem performance tests of
> yesteryear would use an otherwise empty partition, and run newfs
> before populating with whatever sample data they were going to
> run against.

I think the test tools in question create a new file, use it, then delete=
=20
it. So I think we should be in a comparable fs situation each time.

Take care,

Bill

--7CZp05NP8/gJM8Cl
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFE6jNIWz+3JHUci9cRAgiCAJ4shltKrQKzqAG7wpGXF7Ucn0O1+gCcCIPp
Hy4y4HiefqQ+E2ncLpPMUxk=
=TBRk
-----END PGP SIGNATURE-----

--7CZp05NP8/gJM8Cl--