> From: "Jarommr" Dolecek <jdolecek@netbsd.org>
>
> Ross Harvey wrote:
> > I would suggest the following, perhaps obvious, cautions.
> > 
> >      o 	It really should have its own SMP-safe lock calls, but it
> >		doesn't.
>
> lockmgr(9), or would just spinlocks do ?

Either one can be made to work for this, depending on what they are
wrapped around.

> > 	its own SMP locks, as it adds an entire third I/O type to the
> > 	previous choice of merely: vnode or socket.
>
> I think it makes sense to do this for the very special beings pipes
> are. Pipes are the very  centre of unix model and it's definitely worth it
> to make them as efficient as possible, IMHO. Even through it's
> good to have generic interfaces, the layering might add too
> much burden with little to no gain in this case.

You were doing fine right up until you started hand-waving about "efficiency".
I really wish we could filter these discussions philosophically, because
whenever someone trys to defend a kludge against an architectural argument
(which often they don't understand) the rationale for doing the kludge is
"but your correct implementation might be slower, some [vague and
unstated] efficiency concern justifies my ugly kludge."

I'm _not_ saying mine is architecturally correct vs your proposal, nor am
I saying yours is a kludge. That was a general statement about the usual
problem with hand-waving allusions to hinted-at "inefficiences". Since
yours is not obviously a kludge, it's even more of a shame that you've
quickly strayed from perfectly good architectural arguments to the hand-
waving efficiency FUD that is ALWAYS used (sigh) to defend kludges.

So all I am saying is that architectural concerns should be resolved on
architectural grounds, and then the correct implementation should be made
as fast or faster than the kludge. (If necessary, the correct case can be
translated into and rewritten as the kludge, so it's always possible to go
as fast as the kludge, while preserving the more general interface, or
whatever it is that the kludge lacked.)

Furthermore, I just so wish that people could be prevented from handwaving
about efficiency without even having an argument in the first place. If
speed is in fact a concern, don't say "might add" or "as efficient as
possible". Say it WOULD be too slow, say why if it isn't obvious, and be
prepared to defend it.

I don't think this discussion has reached the point where the speed of a
vnode op vs a pipe op even matters, since we haven't even agreed that vnode
ops are important. I'm not planning on arguing it, and I don't see anyone
else doing so either. Really, settle the architectural matters first.

But since you brought it up, and looking at vn_write(), all I see is a few
bits of (fixable) code to translate F* flags into IO_* flags, a call to a
totally nulled-out nqnfs op, and some lock code that you need anyway. Then
there is another indirect procedure call, but a quick test (note: no hand
waving) shows that doesn't matter:  kernel and pipe ops take about 11 uS
on my old eb164 alpha, so a matter of nanoseconds for another level of
procedure call through a pointer shouldn't matter.

In any case, this optimization is for large amounts of data; the performance
on small data is by definition a small matter.

//ross