The coallescing I/O was done fairly early.
It made other forms of optimization unnecessary
or unhelpful. There are many other optimizations
present in NetBSD. Perhaps the 5% coallescing hits
number instead of the 2:1 or 6:1 reflect well on
the optimizations that are there.

	-gww

> -----Original Message-----
> From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> Behalf Of Stephan Uphoff
> Sent: Wednesday, January 28, 2004 6:39 PM
> To: Gordon Waidhofer
> Cc: Chris Jepeway; tech-kern@NetBSD.org
> Subject: Re: Coallesce disk I/O 
> 
> 
> 
> Hi Gordon,
> 
> This is a working implementation for i386 architectures
> not just a simulator - the numbers are just statistics
> captured while doing "Just In Time" coalescing.
> ( and Chris posted a link to his patch and an offer to update
>  it in his last email )
> 
> I am not surprised about the 6:1 for your proprietary O/S.
> Did you design it for coalescing or was that an afterthought?
> 
> 	Stephan
> 
> 
> 
> > 
> > Nice post, Chris.
> > 
> > Capturing data at strategy() time, then
> > analyzing with simulators 'n' such sounds
> > pretty good. And reasonably cheap compared
> > to implementing working prototype. Neat idea.
> > Do you still have any of those tools around?
> > 
> > I'm surprised by the 5% number. I'd thought
> > it would be higher. Much much higher. I've
> > seen coallescing typically turn 2.5 disk I/Os
> > per file op into an average of 1.2, about half.
> > Certain loads -- lots of write -- were more like
> > 6:1. That was on a proprietary O/S and, as you
> > say, NetBSD is already doing a lot before strategy().
> > In your and Stephan's earlier work what increases
> > did you see?
> > 
> > Cheers,
> > 	-gww
> > 
> > > -----Original Message-----
> > > From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> > > Behalf Of Chris Jepeway
> > > Sent: Wednesday, January 28, 2004 10:44 AM
> > > To: tech-kern@NetBSD.org
> > > Subject: Re: Coallesce disk I/O
> > > 
> > > 
> > > Well, lemme weigh in, here, if I may.
> > > 
> > > I think the VM tricks approach is simple enough that
> > > it makes sense to use it for exploratory purposes,
> > > to, as Stephan says, see if there's a dead rabbit
> > > or gold down at the end of the "how to coalesce
> > > I/O" hole.  If gold, fooling around with the
> > > next step of firming up the implementation
> > > makes sense.  If stinky dead rabbit, well, drop
> > > it in favor of other improvements that give
> > > more bang for the buck.
> > > 
> > > Anecdotal testing--compiling GENERIC on a SCSI
> > > disk manufactured in the past 5 yrs--showed that
> > > 5% of the buffers delivered to strategy were
> > > coalescable, and that coalescing them improved
> > > disk throughput by a corresponding 5%.  As for
> > > execution time, good news/bad news: no extra
> > > CPU time, neither user nor sys; but no better
> > > wall-clock time, either.  At least, that's
> > > what I recall.
> > > 
> > > So, what do I think you can tell from this?
> > > 
> > >     o  there are some I/O requests that can be
> > >        coalesced (at one point, it had been
> > >        put forth that there wouldn't be
> > >        that many, since UVM/UBC/UFS were
> > >        pretty smart about read-ahead and
> > >        write-behind); these are presumed
> > >        to be meta-data writes, but that
> > >        was never confirmed
> > > 
> > >     o  on an 800MHz AMD Duron, the overhead
> > >        of coalescing I/O via VM tricks isn't all
> > >        that much (since there's no change
> > >        in CPU times for the compiles)
> > > 
> > >     o  it'd be easy enough to test how much
> > >        coalescing I/O would help out w/
> > >        whatever's going on in -current;
> > >        if the meta-data theory is correct,
> > >        maybe the bolus of softdep data
> > >        could be softened up by coalescing
> > > 
> > > I'd jump in and do some tests w/ -current, but my devel/test environments
> > > are more-or-less toast.  I'm trying to resurrect them, but what with
> > > this, that, and the other thing, it'll be 2 weeks or so b/4 I
> > > could run any benchmarks.  Meanwhile, I'd be glad to work w/ anybody
> > > interested in using the patches at http://www.blasted-heath.com/nbsd/cluster/
> > > to get solid numbers from -current.  If the patches, for instance, no
> > > longer apply cleanly, I think I've got enough infrastructure left to
> > > cook up a set that would work.
> > > 
> > > Any takers?
> > > 
> > > Chris.
> > > 
> > 
> > 
> 
> 
>