Messages in this thread | | | From | Atish Patra <> | Date | Wed, 22 Feb 2023 16:28:36 -0800 | Subject | Perf event to counter mapping question |
| |
Hi All, We are trying to figure out what is the best approach to define the perf event to programmable counter mappings in RISC-V. Until recently, all the programmable counter/event selector registers were writable in M-mode (highest privilege mode) only. The firmware residing in M-mode would discover the mapping from device tree[1] and the perf driver relies on SBI PMU[2] interface to discover the mapping between event & counters.
There are new ISA extensions being proposed to make counters /event selector register in supervisor mode as well. Thus, a pmu driver can directly program the event selectors without relying on firmware. However, the kernel needs to be aware of counter mapping to do that.
AFAIK, ARM64 allows all-to-all mapping in pmuv3[1]. That makes life much easier. It just needs to pick the next available counter. On the other hand, x86 allows selective counter mapping which is discovered from the json file and maintained in per event constraints[4]. There may be some legacy reasons why it was done in x86 this way[5]. Please correct me if I am wrong in my understanding/assumption.
Here are a few approaches that can be used to solve it in RISC-V.
1. Continue to use device tree bindings Cons: We have to define similar entries for ACPI. It makes virtualization difficult as the VMM has to discover and update the device tree/ACPI as well.
2. Mandate all-to-all mapping similar to ARM64. Note: This is only for programmable counters. If the platform supports any fixed counters (i.e. can monitor only a specific event), that needs to be provisioned via some other method. IIRC the fixed counters(apart from cycle) in ARM64 are part of AMU not PMU.
3. All platforms need to define which subset of events can be monitored using a subset of counters. The platform specific perf json file can specify that. This approach provides more flexibility but makes the code path a bit more complex as the counter mask constraint needs to be maintained per event basis.
4. Any other approach ?
Any thoughts on what would be the best approach for RISC-V. It would be great to repeat any past mistakes in RISC-V by learning from experience from the community.
[1] https://lore.kernel.org/lkml/Y6tS959TaY2EBAdn@spud/T/ [2] https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc#function-find-and-configure-a-matching-counter-fid-2 [3] https://elixir.bootlin.com/linux/v6.2/source/arch/arm64/kernel/perf_event.c#L899 [4] https://elixir.bootlin.com/linux/latest/source/arch/x86/events/core.c#L876 [5] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1978937.html -- Regards, Atish
| |