Subject: Re: Throttling IO Requests in NetBSD via Congestion Control
To: Kurt J. Lidl <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 08/21/2006 15:27:20
Content-Type: text/plain; charset=us-ascii
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=
> > > 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.
> > As one of the mentors for this project, I think changing scheduling
> > priority can/should be investigated after the SoC project completes.
> > I think there are a number of things to look into, like how to apply ba=
> > pressure, and different ways to estimate congestion/decide when we shou=
> > apply back pressure. I have a feeling we may well come up with a number=
> > different things to try.
> 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%=
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=
it. So I think we should be in a comparable fs situation each time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----