Ok, I found my old pipebuf program (attached). Please ignore that the conversion of fractional seconds for the timeout is all wrong, the rest seems to work after all.
Here's a trivial test. The options I'm using are -i for setting stdin (-o would set stdout), and -b bufsize to set the size for bufmod to use. Larger sizes do help, but much less than you might think. First, without using my pipebuf program at all; default pipe buffer size of 5120: $ dd if=/dev/zero bs=5120 count=100000| timex cat >/dev/null 100000+0 records in 100000+0 records out real 2.27 user 0.17 sys 1.85 Now, sort of a control test: just use it to explicitly set the default, which allows us to recognize that the extra process is adding some time: $ dd if=/dev/zero bs=5120 count=100000| pipebuf -i -b5k timex cat >/dev/null 100000+0 records in 100000+0 records out real 2.88 user 0.18 sys 1.96 Increase the pipe buffer size by a factor of 10: $ dd if=/dev/zero bs=5120 count=100000| pipebuf -i -b50k timex cat >/dev/null 100000+0 records in 100000+0 records out real 2.12 user 0.12 sys 1.63 and again: $ dd if=/dev/zero bs=5120 count=100000| pipebuf -i -b500k timex cat >/dev/null 100000+0 records in 100000+0 records out real 2.11 user 0.11 sys 1.62 For the heck of it, I did a truss of one of these, and found that cat was always reading 8192 bytes at a time. So I tried with 40k (400k) instead of 50k (500k) (since 40 or 400 would divide evenly by both 5 and 8, which 50 or 500 wouldn't), and it did a tiny bit better: $ dd if=/dev/zero bs=5120 count=100000| pipebuf -i -b40k timex cat >/dev/null 100000+0 records in 100000+0 records out real 2.11 user 0.11 sys 1.58 $ dd if=/dev/zero bs=5120 count=100000| pipebuf -i -b400k timex cat >/dev/null 100000+0 records in 100000+0 records out real 2.09 user 0.11 sys 1.59 So, this demonstrates that changing the pipe buffering does indeed produce some (slight) improvement, although it hardly seems impressive compared to the Dragonfly BSD case. It also demonstrates that picking a common multiple of the read and write sizes (if mismatched) produces the best results, and that even the least common multiple is better than a far larger size that isn't a common multiple. Some new operation which could perhaps be introduced that could achieve the same effect (rather than pushing pipemod and bufmod, and then setting buffed to the desired behavior) might be a bit more efficient still, and probably more convenient. I don't know that this fits the ulimit model well though, because it's certainly not a limit (i.e. no hard limit that only root can increase). If someone wants to play with the pipe as socketpair scenario (I'm not that interested, after a night shift), the code for an LD_PRELOADable implementation is trival, and also attached. It might be fun if someone did some tests with that as well. However, that would require some additional code to use setsockopt to set the socket high water mark to achieve similar adjustability. Since I can't keep my eyes open right now, that is "left as an exercise to the reader". -- This message posted from opensolaris.org
pipebuf.c
Description: Binary data
pipe_as_socket.c
Description: Binary data
_______________________________________________ shell-discuss mailing list shell-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/shell-discuss
