Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
prattmic opened this issue Feb 21, 2024 · 2 comments
Open

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

prattmic opened this issue Feb 21, 2024 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@prattmic
Copy link
Member

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
@prattmic prattmic added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 21, 2024
@prattmic prattmic added this to the Backlog milestone Feb 21, 2024
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 21, 2024
@gopherbot
Copy link

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

@rhysh
Copy link
Contributor

rhysh commented Apr 18, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Go Compiler / Runtime
Status: Todo
Milestone
Backlog
Development

No branches or pull requests
3 participants
@rhysh @prattmic @gopherbot