Re: A proposal to enhance RISC-V HPM (Hardware Performance Monitor)
|
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.
Regards, Anup
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. |
|
|