Skip to content

[Windows] Implement support for the cpu-clock perf pseudo-counter #897

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

Open
Tracked by #834
wesleywiser opened this issue Jul 8, 2021 · 2 comments
Open
Tracked by #834
Labels
O-windows An issue specific to the Windows OS

Comments

@wesleywiser
Copy link
Member

The Linux perf tool has a counter called cpu-clock which is basically just the total time the process was running on each thread. (As a simple example, suppose a process runs for 3 seconds on 1 core and, at the same time, 1 second on another core, then the cpu-clock would read 4 seconds)

This counter isn't backed by a hardware performance counter, rather it is a metric derived from some hardware performance counters and as such, doesn't exist on Windows. However, we can replicate the counter ourselves.

To do that, we'll need to keep track of the times each thread we care about spends active on a core and sum the total times together. We may be able to use the Timestamp data already collected in the trace file for this purpose or we may need to use the Time (or TimerFixed?) PMC.

// FIXME(wesleywiser): We should be properly calculating this value by taking the total time
// each rustc thread runs per core and adding them togther. This placeholder value is here
// so that we can still render the detailed query statistics page (although the "Time (%)"
// column will show the wrong value).
cpu_clock: 1.0,

// FIXME(wesleywiser): see comment in `<Counters as Default>::default()`.
cpu_clock: 0.0,

After this is implemented, the detailed self-profile query results page should show reasonable numbers in the total "Time %" cell.

image

@wesleywiser wesleywiser mentioned this issue Jul 8, 2021
6 tasks
@Mark-Simulacrum
Copy link
Member

FWIW it was my perspective when implementing this to explicitly not use trace data from the self-profile data because I wanted to expose disparity in what the kernel(?) thought and what the profiling data thought. However, this may not be the best way to get that exposed, and we may not care.

@wesleywiser
Copy link
Member Author

To clarify, by "the trace file" I meant the results of tracelog/xperf not the self-profile data which should be conceptually equivalent to the perf data on Linux.

@rylev rylev added the O-windows An issue specific to the Windows OS label Jul 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-windows An issue specific to the Windows OS
Projects
None yet
Development

No branches or pull requests

3 participants