Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)

Anup Patel

Hi Alan,


Thanks for the data points. The proposed SBI_PMU_COUNTER_CONFIG_MATCHING will helps us minimize SBI calls for configuring HPMEVENT CSR. I am not sure if you have considered latest SBI PMU extension proposal for benchmarking.


My question in-context of Hypervisors is still unanswered. The existing HPMCOUNTER CSRs are in read-only CSR range. We will need separate CSR range from S-mode Read-Write CSRs. Further, we will also need separate CSRs from HS-mode to save-restore VS-mode HPMCOUNTER CSRs states.


A more general question is that is it worth to add so many CSRs and add increase overhead for Hypervisors just to make HPMCOUNTER writeable form HS-mode and VS-mode. We should also consider the fact the Linux perf will be mostly used for debugging and analysis.





From: tech-privileged@... <tech-privileged@...> On Behalf Of alankao
Sent: 18 August 2020 14:12
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] A proposal to enhance RISC-V HPM (Hardware Performance Monitor)



Hi Anup,


Fair enough.  Of course, your conclusion is totally correct: "we CAN EASILY set the HPM* ...," but the real question here is in point 1: Are counter updates really that in-frequent so?  So far, nobody provided any convincing pieces of evidence. Yet, I would like to share our findings from an out-of-the-box experiment.


The system for testing is a 4.17-based Linux branch which contains andes_pmu patch, running on our A27 design on FPGA.  The testing command was 


time perf record -e cache-references ./whestone


where "cache-references" is an andes_pmu cache event and the target program is a normal whestone executable.  We tested three different settings,


Baseline: all HPM CSRs are written in S-mode using plain csr_write.

SBI1: HPM counter CSRs are written with SBI calls.
SBI2: HPM counter and event CSRs are written with SBI calls.

We ran each of them 20 times and calculate the average of "real" part of the output.  It turns out that, (in seconds)
Baseline:  23.131
SBI1: 24.840 (increasing 7.4% more time from baseline)
SBI2: 25.691 (increasing 11.1% more time from baseline)

Considering the result, does the write-enable bit count as a benefit now?
Also, it's perfectly fine that QEMU virt platform doesn't support PMUs which allow S-mode to write HPM CSRs, so I don't think #279 answers #280 and #278.


Join to automatically receive all group messages.