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 serious
> > 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 back 
> pressure, and different ways to estimate congestion/decide when we should 
> apply back pressure. I have a feeling we may well come up with a number of 
> 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.

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

-Kurt