Skip to content

ui: Arm telemetry cpu manager, telemetry plugin, and page to load cpus#5284

Open
abhmen01 wants to merge 3 commits intogoogle:mainfrom
pan-:ui-arm-telemetry-cpu-manager-and-telemetry-plugin
Open

ui: Arm telemetry cpu manager, telemetry plugin, and page to load cpus#5284
abhmen01 wants to merge 3 commits intogoogle:mainfrom
pan-:ui-arm-telemetry-cpu-manager-and-telemetry-plugin

Conversation

@abhmen01
Copy link
Copy Markdown

@abhmen01 abhmen01 commented Mar 25, 2026

ui: Add Arm CPU telemetry support

Introduce the main pieces of the Arm telemetry solution:

  1. Add ArmTelemetrySpec plugin to parse, store, and expose Arm CPU telemetry
    specifications.

  2. Add a UI page under the sidebar support section to load and inspect
    Arm CPU specifications in a tree view.

  3. 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.

@abhmen01 abhmen01 requested a review from a team as a code owner March 25, 2026 18:06
@google-cla
Copy link
Copy Markdown

google-cla Bot commented Mar 25, 2026

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.

Copy link
Copy Markdown
Member

@primiano primiano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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({
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same thing here. none of this belong to the public/ API surface

@stevegolton stevegolton self-requested a review March 27, 2026 14:41
@abhmen01 abhmen01 force-pushed the ui-arm-telemetry-cpu-manager-and-telemetry-plugin branch from d08e6ed to 9d31eb1 Compare March 31, 2026 15:22
@abhmen01
Copy link
Copy Markdown
Author

abhmen01 commented Apr 6, 2026

@primiano Thanks for the comments. I will work on the layering of the code.

@abhmen01 abhmen01 force-pushed the ui-arm-telemetry-cpu-manager-and-telemetry-plugin branch from 9d31eb1 to ff2ca76 Compare April 20, 2026 17:04
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.
@abhmen01 abhmen01 force-pushed the ui-arm-telemetry-cpu-manager-and-telemetry-plugin branch from ff2ca76 to b7f9cff Compare April 21, 2026 13:36
@abhmen01
Copy link
Copy Markdown
Author

Hi @primiano
I have re-architectured the code by splitting it into focused plugins

  • com.arm.ArmTelemetrySpec: owns the shared Arm telemetry spec manager/registry, including parsing, validation, registration, and lookup of loaded CPU specs.
  • com.arm.ArmCpuPage: provides the UI page under Support for loading and browsing Arm CPU specs. It depends on ArmTelemetrySpec and updates the shared spec registry through that plugin.
  • com.arm.ArmTelemetry: consumes the shared spec registry to expose trace-side Arm telemetry and derived metric functionality.
  • com.arm.ArmPmuRecorder: also depends on ArmTelemetrySpec and consumes the shared registry to drive PMU recording configuration from the loaded CPU specs (This is in ui: arm telemetry pmu recording page #5286 )

Can you please look at this?

@@ -0,0 +1,86 @@
// Copyright (C) 2026 The Android Open Source Project
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come this is in its own folder, but isn't a PerfettoPLugin?


static onActivate(app: App) {
app.pages.registerPage({
route: '/cpu',
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this? Feels like you shoudl inject this into our dependencies rather than leaking into a static. where is this used?

@primiano
Copy link
Copy Markdown
Member

primiano commented Apr 21, 2026

Hey thanks, looks much better. a few questions, see comments above

My main high level questions:

  1. What is that Spec thing doing? it's not a real plugin.
  2. The plugin ID should match the directory name, like the others
  3. The injection of that static seems a bit weird. why isn't that jinjected

A lot of that injection can be largely avoided using the ctx.plugins.getPlugin(ClassName)
That returns an instance of the per-trace plugin instantiation, which avoid all the plumbing through the static member you are doing.

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);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the settimeout here?

}

this._ctx = ctx;
this._metricsThrash = new AsyncDisposableStack();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Thrash/trash/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants