Thus spake Thor Lancelot Simon ("TLS> ") sometime Today...

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

I think it's laudable to do this sort of thing MI, but if it's not
practical to do so, perhaps having it MD, or at least group-of-M-D
[naming the identifiers and pulling them in via some conditional
mechanism (compile-time might look uglier, but it's probably more
efficient than run-time)] would be the best way to go.

i.e. i386/sparc/alpha might work best with method A, vax/mips/m68k
might work best with method B, etc.  If I understand correctly,
there aren't a whole slough of different ways to do this; perhaps
three, maybe four.

It seems inelegant on the surface, I'm sure, but if one size doesn't
fit all, we shouldn't be trying to shoehorn it.

This is from someone who is Not A Kernel Engineer.

[reading further...]

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

I would agree, as long as we keep in mind that the long-term solution
should not degrade performance from the "tricks".

TLS> However, I'm pretty sure I/O coalescing is not the way out of the hole
TLS> we're currently in.

Perhaps not the way completely out, but it appears to be part of it.
The hole seems to me to be more complex than "just a hole".

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

To my untrained eye, it's not all sitting in the buffer cache, either,
though.  I think, to quote a famous writer, "the way out is through".
In short, the path lies somewhere in the middle.

Has anyone taken the time to profile the kernel -- specifically, of
course, the I/O system -- or is that another one of those things which is
Not Yet Working?  I ask only because we see a lot of "well, this looks
broken, and that looks broken, and as of this update/major change,
performance has been drawn through the grate"; in short, quite a bit of
speculation.

[But I seem to recall something about kernel profiling Not Quite Working.]

Apologies if my ignorance on this offends anyone, or if I'm way off
base.  I'm always learning -- please be kind.

				--*greywolf;
--
22 Ways to Get Yourself Killed While Watching 'The Lord Of The Rings':

#1: Stand up halfway through the movie and yell loudly, "Wait...where the
    f**k is Harry Potter?"