> Capturing data at strategy() time, then
> analyzing with simulators 'n' such sounds
> pretty good. And reasonably cheap compared
> to implementing working prototype. Neat idea.
As Stephan wrote, this is a working prototype,
coalescing sequential buf's using VM tricks.

> Do you still have any of those tools around?
There are simple counters in the code.
The 5% came from those counters while
doing a generic kernel build.

That's hardly sufficent testing, but it
is an existence proof: some I/O can be
coalesced.  Really, that's all it is until
more tests are done.  In the past year+,
I've never gotten around to doing them.

I don't suppose you've got a setup where
you could run some real benchmarks?  Anybody?
As I wrote, I can probably handle beating
around the patch so it applies and compiles
against -current, if there's interest.

> [ reports of 6:1 coalescing ]. 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?
No real numbers, other than the above.
I'm guessing NSS had enough experience w/
their own proprietary O/S to say "hey, we
know we can gain piles of simplicity in
our file system code if our I/O's get coalesced
b/4 they hit the disk driver."  Sounds like your
results, too.

One further thing to point out about coalescing
buffers as they come out of the BUFQ: it only
helps when the disk is busy.  If the driver
schedules the I/O before sequential requests
build up in the BUFQ, there won't be anything to
coalesce.  This is where the Anticipatory Scheduler
from Linux makes sense: it introduces some delays
b/4 scheduling I/O, so that successive requests
can build up to be, among other things, coalesced.
At least, that's what I understand it to do.

> 	-gww
Chris.