From 0ff8d14c501d1459b4c2524ce62c802b10952eed Mon Sep 17 00:00:00 2001 From: Dmitriy Ryabtsev Date: Mon, 26 Feb 2024 15:14:38 +0300 Subject: [PATCH] Update charter based on offline discussions --- charter.adoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/charter.adoc b/charter.adoc index aad44ca..a25c7d2 100644 --- a/charter.adoc +++ b/charter.adoc @@ -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 consider such working model and may suggest some improvements for the Linux perf to support it. + +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.