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.

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

runtime: measure actual CPU time of GC #19497

aclements opened this issue Mar 10, 2017 · 0 comments

runtime: measure actual CPU time of GC #19497

aclements opened this issue Mar 10, 2017 · 0 comments


Copy link

@aclements aclements commented Mar 10, 2017

Currently, the CPU time we report for GC in the gctrace is based on the assumption that each GC worker actually gets the CPU for the full wall-clock duration it runs for. This is a bad assumption on over-subscribed systems. We've seen this internally when users set GOMAXPROCS too high or have other processes in the same cgroup that consume too much CPU and the cgroup throttles execution. This may also be relevant to #19378.

We should consider asking the OS for actual CPU consumed by GC and reporting that. Comparing this with wall-clock time in the gctrace will give both us and users a better sense of any environmental problems causing long GC phases.

We should also consider how GC pacing would be affected by measuring actual CPU time versus wall-clock CPU time.

/cc @RLH

@bradfitz bradfitz added this to the Go1.9Maybe milestone Mar 21, 2017
@aclements aclements added this to the Go1.10 milestone Jul 18, 2017
@aclements aclements removed this from the Go1.9Maybe milestone Jul 18, 2017
@rsc rsc removed this from the Go1.10 milestone Nov 22, 2017
@rsc rsc added this to the Go1.11 milestone Nov 22, 2017
@gopherbot gopherbot removed this from the Go1.11 milestone May 23, 2018
@gopherbot gopherbot added this to the Unplanned milestone May 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants