Re: Coallesce disk I/O (was RE: Interactive responsiveness under heavy I/O load)

On Mon, Jan 26, 2004 at 06:52:37PM -0500, Stephan Uphoff wrote:
>  
> When I initially wrote the file system for Network Storage Solution
> they had a proprietary kernel and I could use scatter/gather for
> I/O coalescing.
> 
> Porting to NetBSD we had Chris Jepeway implement clustering using 
> (architecture specific)
> MMU tricks.

I personally find this quite useful -- and it should be possible to do
entirely using MI calls into the UVM subsystem.  The problem is that
I/O coalescing by creating page aliases using the MMU is incredibly
inefficient on some architectures, either because of the cache flushing
it forces or because of the cost of MMU operations.  For that reason,
a number of developers are strongly opposed to integrating *that
particular* kind of I/O coalescing implementation into NetBSD.

I'm a bit less absolutist about it.  I'd personally prefer that we
played such tricks where they were reasonably cheap and effective,
even if a more general implementation using physical addresses for I/O
or chains of buffers were chosen as a long-term solution.  

However, I'm pretty sure I/O coalescing is not the way out of the hole
we're currently in.  Fixing the syncer is one key part of the problem;
managing to more effectively apply backpressure on writers (including
softdep's stream of directory and metadata updates) so that they do not
behave in a bursty manner is another.  But I do not see the applicability
of I/O coalescing to either of these problems, and I do not see evidence
that we are causing ourselves the current trouble by generating many
small contiguous I/O operations, which is the problem that coalescing
would solve; in fact, I see a great deal of evidence that the causes
of the problem lie elsewhere.

Thor