-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Add PID to PGO profile data filename #97110
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
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit cb61b975d3f0595f006725497d2544baeca02c52 with merge c9f0f31b6e23192d7c066d87758706b79ebde0b1... |
☀️ Try build successful - checks-actions |
Queued c9f0f31b6e23192d7c066d87758706b79ebde0b1 with parent 7355d97, future comparison URL. |
Finished benchmarking commit (c9f0f31b6e23192d7c066d87758706b79ebde0b1): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
cb61b97
to
19a3558
Compare
@Mark-Simulacrum While playing with PGO, me and @lqd have noticed that the generated profile files are being re-written and merged all the time. When By adding the PID placeholder ( It generates ~20 GiB more space on disk on the CI run, but that seems harmless (?). Merging the profiles is not a bottleneck, the perf. run took the same amount of time as usually (~1h 24m). |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 19a3558 with merge 524d12d1a77cff27739df8f27668cd58d821e35b... |
Seems alright. If you can put that in the PR description that would be great, much easier to find in the future. |
After this perf run, let's also try it with LLVM profiling data, which will be in edit: in another PR will be fine. |
☀️ Try build successful - checks-actions |
Queued 524d12d1a77cff27739df8f27668cd58d821e35b with parent 3655175, future comparison URL. |
Finished benchmarking commit (524d12d1a77cff27739df8f27668cd58d821e35b): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Footnotes |
I feel we've stumbled into some unexpected/interesting/strange unstability and non-determinism issues here. The perf runs seem to agree there's something to our discovery though, so: @bors r+ |
📌 Commit 19a3558 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e5732a2): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
…crum Add PID to LLVM PGO profile path This is a continuation of rust-lang#97110, which adds PID to the filename pattern of LLVM profiles. It also adds some metrics to the pgo.sh script, so that we can observe how many profiles there are and how large are they. r? `@lqd`
After experimenting with PGO, it looks like the generated profile data files can be sometimes overwritten if there is a race condition, because multiple
rustc
processes are usually invoked in parallel bycargo
. Adding the PID to the resulting profile filename pattern makes sure that the profiles will be stored in separate files.This generates ~20 GiB more space on disk on the CI run, but that seems harmless (?). Merging the profiles is not a bottleneck, the perf. run took the same amount of time as usually (~1h 24m).
r? @lqd