Messages in this thread | | | From | Anup Patel <> | Date | Thu, 23 Feb 2023 08:25:31 +0530 | Subject | Re: Perf event to counter mapping question |
| |
On Thu, Feb 23, 2023 at 5:58 AM Atish Patra <atishp@atishpatra.org> wrote: > > 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 ?
I suggest a 4th approach where by default the kernel assumes all-to-all mappings and optionally perf json file can be used to override mappings for certain counters. This approach is more like a hybrid approach between approach #2 and #3. It work fine with KVM RISC-V as well because Guest/VM will assume all-to-all mapping for logical HW counters whereas Host can have specific counter mappings.
> > 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
Regards, Anup
| |