ui: Arm telemetry cpu manager, telemetry plugin, and page to load cpus#5284
ui: Arm telemetry cpu manager, telemetry plugin, and page to load cpus#5284abhmen01 wants to merge 3 commits intogoogle:mainfrom
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
primiano
left a comment
There was a problem hiding this comment.
Sorry folks, as much as I'm excited by seeing this coming, and i'm overal supportive of what you are doing, the layering in this PR is too wrong.
you can't have code in core that knows so much about the details of arm CPUs
This defeats the all core vs plugin split.
This PR needs to be better architected. It can't fly as-is
If you look at the rest of core and public/ we put a lot of efforts to make sure that they are Platform-agnostic as much as we could.
| // structure the performance analysis. | ||
|
|
||
| // Description of an event | ||
| const ARM_TELEMETRY_PMU_EVENT_SCHEMA = z.object({ |
There was a problem hiding this comment.
same thing here. none of this belong to the public/ API surface
d08e6ed to
9d31eb1
Compare
|
@primiano Thanks for the comments. I will work on the layering of the code. |
9d31eb1 to
ff2ca76
Compare
Add a new UI plugin for Arm CPU telemetry specifications. Introduces the ArmTelemetryManager interface for parsing, storing, and accessing the telemetry specifications. These specifications are unique to Arm CPU cores and include: - Events: PMU events available on the core. - Metrics: Computed from events for performance analysis. - Groups: Coherent collections of events or metrics. - Methodology: Describes how to conduct performance and micro-architecture analysis using the available metrics. The ArmTelemetryManager is initialized when the plugin is activated, so other plugins can access the shared telemetry spec registry.
Add an ArmCpuPage plugin under the Support sidebar section. The page lets users load Arm CPU specification files and inspect the currently loaded specs in a tree view. The plugin depends on ArmTelemetrySpecPlugin for spec parsing and validation, and updates the shared telemetry spec registry so the loaded specs are available to other Arm telemetry features.
Introduce a plugin that leverages Arm telemetry specifications to create metric tracks from PMU counters available in a trace. The generated tracks are grouped under the standard "Hardware" category, within a single node titled "CPU Metrics". The plugin also exposes tables of counters and derived metrics in the SQL database. For example, if the trace contains "INST_RETIRED" and "CPU_CYCLES" counters and the loaded specification defines a metric named "IPC" computed as "INST_RETIRED / CPU_CYCLES", the plugin will: - Generate individual tables for "inst_retired" and "cpu_cycles", with values normalized and set to 0 when the CPU is idle. - Compute a new derived table for "ipc" using the metric's formula. - Create a track from the "ipc" table and display it in the workspace with the other CPU metrics.
ff2ca76 to
b7f9cff
Compare
|
Hi @primiano
Can you please look at this? |
| @@ -0,0 +1,86 @@ | |||
| // Copyright (C) 2026 The Android Open Source Project | |||
There was a problem hiding this comment.
How come this is in its own folder, but isn't a PerfettoPLugin?
|
|
||
| static onActivate(app: App) { | ||
| app.pages.registerPage({ | ||
| route: '/cpu', |
There was a problem hiding this comment.
I suggest you take a route which is a bit more specific, like /arm_cpu
/cpu might get used by us at some point in the future
| private static manager: ArmTelemetryManager; | ||
|
|
||
| static onActivate(app: App): void { | ||
| ArmTelemetrySpecPlugin.manager = new ArmTelemetryManagerImpl(app); |
There was a problem hiding this comment.
why this? Feels like you shoudl inject this into our dependencies rather than leaking into a static. where is this used?
|
Hey thanks, looks much better. a few questions, see comments above My main high level questions:
A lot of that injection can be largely avoided using the ctx.plugins.getPlugin(ClassName) See other precedent for using ctx.plugins.getPlugin in the codebase also add OWNERS |
| this._ctx.trash.use( | ||
| telemetrySpecManager.addOnChangeCallback( | ||
| (_change: 'ADD' | 'REMOVE' | 'UPDATE', _desc: ArmTelemetryCpuSpec) => { | ||
| setTimeout(() => this.updateMetricTracks(), 0); |
| } | ||
|
|
||
| this._ctx = ctx; | ||
| this._metricsThrash = new AsyncDisposableStack(); |
ui: Add Arm CPU telemetry support
Introduce the main pieces of the Arm telemetry solution:
Add ArmTelemetrySpec plugin to parse, store, and expose Arm CPU telemetry
specifications.
Add a UI page under the sidebar support section to load and inspect
Arm CPU specifications in a tree view.
Add the Arm telemetry plugin to generate counter and derived metric
tables from PMU data, and create CPU metric tracks under the
Hardware / CPU Metrics group.