The experiment put a Go process and a quiet HTTP server in one cgroup. The Go process built a pointer-rich object graph. Memory pressure pushed cold pages to swap. When the runtime entered a stop-the-world phase and touched collector metadata, the kernel had to fetch those pages from storage.
A BPF probe counted 228 page faults inside the worst pause. It attributed 39,013 of the 39,902 microseconds to those faults. That is the useful shape of the result. The runtime pause supplied the critical section. Evicted pages supplied most of its duration.
A pause label names the event. It does not name the cause.
The application path paid a separate bill
The same report measured a 511 KiB message that usually took 3 to 5 milliseconds to build. Under the tested conditions it took 105 milliseconds on NVMe and 903 milliseconds on a network volume. The author did not confirm where all of that time went. Keep it as an observed application delay, not a proved page-fault attribution.
This distinction prevents a common postmortem failure. One measured interval can support a causal claim when the fault probe covers that interval. A nearby slowdown needs its own trace.
Go and Linux expose different witnesses
The Go garbage collector guide recommends execution traces for rare latency events and documents GODEBUG=gctrace=1 for collector-specific records. Linux Pressure Stall Information reports CPU, memory, and I/O stall time for the system or a cgroup. Neither witness replaces the other.
Use the runtime trace to locate the collector phase. Use fault tracing to account for blocked time. Use pressure data to show whether the host or cgroup was starved. Then attach the affected request, queue, or message so the infrastructure event has a product consequence.