You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
comms/uniflow: instrument the receive path across the controller and the transport (meta-pytorch#3905)
Summary:
Pull Request resolved: meta-pytorch#3905
Folded from two adjacent diffs; each half is stated separately below so the two
arguments stay reviewable on their own terms.
--- controller: recv header-wait and payload-drain timings (was D117632427) ---
TcpConn::syncRecv() populates the existing RecvPhaseStats with the time spent
waiting for the length prefix versus draining the payload, plus frame and byte
counts. Splitting the two phases is what makes a slow receive interpretable: a
large headerWaitNs means we were waiting on the peer, while a large
payloadDrainNs means the socket itself was the limit.
All four counters are relaxed fetch_add on atomics already declared in
Controller.h, so this adds two steady_clock reads per frame and no
synchronisation.
--- transport: receive-slab hits, misses and vector receives (was D117632428) ---
Adds receiveSlabAttempts_, receiveSlabMisses_, and vectorReceiveCount_ to
TcpTransport and reports them on the existing tcp phases log line. A miss means
the reader could not get a pinned slab and fell back to a vector-backed
receive, which changes the H2D path for that frame, so distinguishing the two
is necessary before drawing conclusions from an aggregate drain number.
The counters are relaxed atomics incremented in readerLoop().
Differential Revision: D117632428
0 commit comments