cmd/internal/pgo: accept CPU profiles from external tools like Linux perf by geekswaroop · Pull Request #81104 · golang/go

geekswaroop · 2026-08-25T15:46:44Z

PGO consumes a CPU pprof profile, but FromPProf only accepted the value
types emitted by Go's own runtime/pprof ("samples"/"count" and
"cpu"/"nanoseconds") and rejected everything else with a hard error. This
blocked CPU profiles produced outside the Go runtime, most notably Linux
perf profiles converted with perf_data_converter (perf_to_profile), which
name their sample values after the profiled event (e.g. "cycles_event"/
"count") rather than using Go's names.

Such profiles are still CPU profiles: PGO only reads the selected value as
an edge weight and thresholds it as a fraction of the total, so the value's
name and unit do not affect the result beyond selecting the column. When no
Go-native CPU value type is present, select the column via the profile's
default sample type (falling back to the last value type when unset, per the
pprof format), while still rejecting value types from known non-CPU profiles
(heap, mutex, block) so that passing e.g. a heap profile to -pgo still fails
clearly.

The other blocker noted on the issue, missing Function.start_line in
symbolized perf profiles, was fixed separately in google/pprof and is
already vendored into the toolchain, so no change is needed here for it.

Fixes #64489

…perf PGO consumes a CPU pprof profile, but FromPProf only accepted the value types emitted by Go's own runtime/pprof ("samples"/"count" and "cpu"/"nanoseconds") and rejected everything else with a hard error. This blocked CPU profiles produced outside the Go runtime, most notably Linux perf profiles converted with perf_data_converter (perf_to_profile), which name their sample values after the profiled event (e.g. "cycles_event"/ "count") rather than using Go's names. Such profiles are still CPU profiles: PGO only reads the selected value as an edge weight and thresholds it as a fraction of the total, so the value's name and unit do not affect the result beyond selecting the column. When no Go-native CPU value type is present, select the column via the profile's default sample type (falling back to the last value type when unset, per the pprof format), while still rejecting value types from known non-CPU profiles (heap, mutex, block) so that passing e.g. a heap profile to -pgo still fails clearly. The other blocker noted on the issue, missing Function.start_line in symbolized perf profiles, was fixed separately in google/pprof and is already vendored into the toolchain, so no change is needed here for it. Fixes golang#64489

gopherbot · 2026-08-25T16:13:16Z

This PR (HEAD: bb77fa4) has been imported to Gerrit for code review.

Please visit Gerrit at https://go-review.googlesource.com/c/go/+/819781.

Important tips:

Don't comment on this PR. All discussion takes place in Gerrit.
You need a Gmail or other Google account to log in to Gerrit.
To change your code in response to feedback:
- Push a new commit to the branch used by your GitHub PR.
- A new "patch set" will then appear in Gerrit.
- Respond to each comment by marking as Done in Gerrit if implemented as suggested. You can alternatively write a reply.
- Critical: you must click the blue Reply button near the top to publish your Gerrit responses.
- Multiple commits in the PR will be squashed by GerritBot.
The title and description of the GitHub PR are used to construct the final commit message.
- Edit these as needed via the GitHub web interface (not via Gerrit or git).
- You should word wrap the PR description at ~76 characters unless you need longer lines (e.g., for tables or URLs).
See the Sending a change via GitHub and Reviews sections of the Contribution Guide as well as the FAQ for details.

gopherbot · 2026-08-25T16:30:52Z

Message from Gopher Robot:

Patch Set 1:

(1 comment)