Track pipe(2) reads and writes as rusage message receives and sends, a feature misplaced during the transition from BSD 4.4's socket implementation to the optimised FreeBSD pipe implementation.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
This is probably fine, but I am not sure what the semantics of the rusage fields are (completed or attempted send/receive events).
| sys/kern/sys_pipe.c | ||
|---|---|---|
| 721 | Maybe the increment should happen after the initial error checks since the manpage says ru_msgrcv = the number of IPC messages received. | |
| 824 | Or maybe even down here? | |
| 1068 | Same here (the number of IPC messages sent). Not sure whether that should be attempts or completed sends. | |
Comment Actions
Shift points where we count messages received or sent to the end of
pipe_read() and pipe_write() so that they count only messages that were
definitely processed. This is somewhat stronger semantics than are
provided for sockets, but since it costs neglibly more to do this, and
the results are potentially more useful, go with that.
(Suggested by Alex Richardson.)
| sys/kern/sys_pipe.c | ||
|---|---|---|
| 721 | For better or worse, I've largely reproduced the existing structure as found in sockets, etc. I've now updated the patch to move both message counts to points where we are committed to sending or receiving a message, since we can provide stronger semantics at no real cost. Thanks! | |
Comment Actions
I believe these are good places to add the accounting. They do assume that ANY read or ANY write, even one that also have an error, counts as a message rcv or snd, but I think that's OK.
Comment Actions
The socket code is pretty slapdash about accuracy here, as, it turns out, was the original 4.4 pipe code, so my general feeling is that it's adequately OK for this purpose.