Skip to content
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

Update charter based on offline discussions #1

Merged
merged 3 commits into from
Mar 1, 2024
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions charter.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

The RISC-V hardware performance monitoring counters (Zihpm) provide support for counting programmable performance events. Such events can provide insights into software execution behavior, insights that are critical when tuning a profiled workload. However, no performance events are standardized, which means profiling tools must comprehend a custom set of events specific to each hardware implementation. This prevents profiling tools from offering general-purpose, event-based analysis capabilities that can be employed regardless of the underlying hardware implementation.

The Performance Events TG will develop an ISA extension that includes a set of standard performance events and metrics (or formulas of events). For each standard event, the name and the precise hardware behavior associated with it will be specified, though the event selector value associated with the event will be left up to implementations. For each standard metric, the name and event formula, including the names of the constituent events, will be defined.
The Performance Events TG will develop a non-ISA extension that includes a set of standard performance events and metrics (or formulas of events). For each standard event, the name and the precise hardware behavior associated with it will be specified, though the event selector value associated with the event will be left up to implementations. For each standard metric, the name, precise description, and event formula, including the names of the constituent events, will be defined.

The TG will consider whether RISC-V-specific changes are needed to standard JSON file formats used by tools to map event names to event selector encodings, and to map metric names to event formulas. The TG will further prototype the end-to-end solution using Linux perf and Spike, ensuring that perf can properly translate event and metric names, and that, for deterministic events and metrics, the resulting counter and metric values match expectations.
There could be cases when a microarchitecture decide to not implement a performance event in hardware and provide a metric for it instead. Also from the profiling tools users point of view distinction between events and metrics looks not important – e.g. for them everything can be a metrics whether it is implemented as complex formula or mapped directly to a hardware event. The group will further consider whether some standard events may themselves be counted using event formulas rather than direct hardware events, and what tool improvements may be needed to support such implementations.
dr-sc marked this conversation as resolved.
Show resolved Hide resolved

The TG will consider whether RISC-V-specific changes are needed to standard JSON file formats used by tools to map event names to event selector encodings, and to map metric names to event formulas. The TG will further prototype the end-to-end solution using Linux perf and QEMU, ensuring that perf can properly translate event and metric names.