STREAMS overhead (was: SVR3.0 vs BSD4.3)

[Doug McCallum]

In article <7526 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>The only data copy that should normally take place is between user-mode
>data space and the nearest streams buffer, also between the farther
>streams buffer and the net device.  Streams module-to-module data
>transfer should occur by transferring packet pointers whenever possible.
>(I haven't examined SVR3 code to see if this is how it typically does
>things.)

This is exactly how most of the Streams modules I've seen (and all
that I've written) work.  Even splitting a buffer in two usually only
requires duplicating the message block and adjusting pointers if the
data isn't being modified.  This is similar in concept to the mbuf
code in BSD networking but with more buffer sizes.

One possible enhancement that would eliminate some of the copying at
the Stream head would be to detect when user level data falls within a
page and map that page in a copy-on-write manner into the Streams
buffer space.  If the data wasn't modified before it reached the
device, the initial copy would be eliminated.  I haven't thought
through the details and just mention it as a way a specific
implementation can work around the data copy problem in some cases.

In general, the Streams mechanism is no worse than other "buffered"
I/O mechanisms with respect to performance and in many ways is better
(such as the formalized message passing mechanism and variable buffer
sizes).  Probably the biggest problem with Streams in the current
implementations I've seen is the static buffer pool.  That is a
specific implementation issue and not a problem with Streams itself.