Page MenuHomeFreeBSD

Track pipe(3) I/O in rusage
ClosedPublic

Authored by rwatson on Jan 1 2021, 12:38 PM.

Details

Summary

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.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

rwatson retitled this revision from 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. to Track pipe(3) I/O in rusage.Jan 1 2021, 12:40 PM
rwatson edited the summary of this revision. (Show Details)
rwatson added reviewers: gnn, arichardson, jrtc27.
rwatson changed the repository for this revision from rS FreeBSD src repository - subversion to R10 FreeBSD src repository.

Move to freebsd/main from old freebsd/master.

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?

1067

Same here (the number of IPC messages sent). Not sure whether that should be attempts or completed sends.

This revision is now accepted and ready to land.Jan 2 2021, 12:26 AM

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.)

This revision now requires review to proceed.Jan 8 2021, 10:02 PM
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!

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.

This revision is now accepted and ready to land.Jan 8 2021, 10:20 PM
In D27878#626721, @imp wrote:

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.

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.