Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)
|
The most desired feature from a PMU is counting events in right-context (or right-mode). This is not clearly defined in RISC-V spec right now. Greg’s proposal already address this in a clean way by defining required bits in MHPMEVENT CSRs.
Other important feature expected from a PMU is reading counters without traps, this is already available because HPMCOUNTER CSRs are “User-Read-Only”.
Regarding HPMCOUNTER writes from S-mode, the Linux PMU drivers (across architectures) only writes PMU counter at time of configuring the counter. We anyway have SBI call to configure a RISC-V PMU counter because MHPMEVENT CSR is for M-mode only so it is better to initialize/write the MHPMCOUNTER CSR in M-mode at time of configuring the counter. Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much. On the contrary, RISC-V hypervisors might end up save/restore more CSRs if HPMCOUTNER CSR is writeable from S-mode.
The code snippet mentioned below requires “#ifdef” which means we have to build Linux RISC-V image differently for doing CSR writes this way. This approach is not going to fly for distros because distros can’t release single Linux RISC-V image for all RISC-V hardware if we have such “#ifdef”.
Regards, Anup
From: alankao <alankao@...>
Sent: 04 August 2020 12:44 To: Anup Patel <Anup.Patel@...> Subject: Private: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)
The bit[28], or the *mcounterwen* in my original proposal, is essential for better performance versus m-mode register access through SBI or trap-emulation. It is definitely helpful for a simple M-S-U RISC-V system. How many cycles are
you willing to give up just to update the M-mode register every time the kernel handles an HPM interrupt or a context switch? I admit it may not be useful, or even harmful for M-H-S-U system, but it is obvious that a simple RISC-V machine running single OS
kernel can largely benefit from it. |
|
|