runtime: investigate replacing per-thread CLOCK_THREAD_CPUTIME_ID with per-process CLOCK_PROCESS_CPUTIME_ID

[prattmic]

Linux 6.4+ include https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcb7ee79029dcaeb09668a4d1489de256829a7cc, which makes CLOCK_PROCESS_CPUTIME_ID prefer to deliver to the thread that caused timer overflow.

We should check whether CLOCK_PROCESS_CPUTIME_ID suffers from the same multi-expiration problem from #35057. I think it probably does, in which case there is nothing to do. But if it doesn't, going back to a single per-process timer would be a nice simplification.

cc @rhysh @golang/runtime

[gopherbot]

Change https://go.dev/cl/579937 mentions this issue: runtime: try CLOCK_PROCESS_CPUTIME_ID for profiling

[rhysh]

Thanks for the link! I hacked together this change and tried it on an "Ubuntu 22.04.4 LTS" machine running a "6.5.0-27-generic" kernel with "CONFIG_HZ=250". It's available as https://go.dev/cl/579937 if you'd like to see.

Running the test (go test runtime/pprof -run=TestCPUProfileMultithreadMagnitude) under strace -f, I see that there's only one SIGPROF delivery per 4ms kernel tick.

However, because the signal came from a timer_create timer rather than setitimer, its siginfo includes si_overrun. That means we could correct the magnitude at least—an improvement over the starting position of #35057.

But overall from this testing, I don't think we should change the profiler to use a single CLOCK_PROCESS_CPUTIME_ID timer instead of a CLOCK_THREAD_CPUTIME_ID timer for each thread: we'd get less resolution (fewer samples with the same total weight), and the approach is still Linux-specific.