PMU driver in Linux breaks mcycle after use

[Артемий Шушкин]

Hello everyone, when using the perf command, the values ​​of the mcycle minstret registers are broken. Please explain to me why, during the execution of the start function, our init value becomes 0хffffffff...ffff and why it is then written to the register, but after operation does not return the old value.

[Tommy Murphy]

You'd probably need to provide more context info in order to get any useful feedback. E.g. what Linux kernel version, what distro, what RISC-V target implementation, how exactly you are performing your profiling test etc.

Perhaps it would be worth raising the issue in the context of the RISC-V Performance Analysis Tools SIG:

* https://lists.riscv.org/g/tech-announce/topic/announcing_the_formation_of_a/90476927

and/or the LKML?

* https://lkml.org/

[atish patra]

Is it a direct read from user space or via perf tool ?

[Артемий Шушкин]

I use my perf utility, which makes a call to perf event open according to the example in the documentation https://man7.org/linux/man-pages/man2/perf_event_open.2.html. Next, the PMU driver is contacted. The riscv_pmu_add function is called, in which we access the riscv_pmu_start function, where we set the period and get the init val (it is 2^63), after which opensbi is called, which writes this init val in the mcycle. Then the utility itself works correctly and outputs more or less correct values, but after it works, the mcycle becomes approximately 2^63, I use GDB, in which I am running Linux version (6.4.0). GDB shows normal register values ​​before using the utility, and then broken ones. I also noticed that when loading Linux, it writes “Perf sampling/filtering is not supported as sscof extension is not available.” Could the absence of this extension somehow affect this problem?


I cannot understand why it is necessary to write 2^63 during initialization, and then, as far as I understand, not return the previous value.

вторник, 18 июня 2024 г. в 04:14:37 UTC+3, atis...@gmail.com:

[Tommy Murphy]

>  I also noticed that when loading Linux, it writes “Perf sampling/filtering is not supported as sscof extension is not available.” Could the absence of this extension somehow affect this problem?

I suspect that it may - e.g. see here:

* https://forums.sifive.com/t/performance-counters-over-linux/6480/2 

Have you checked the LKML? E.g.:

* https://lore.kernel.org/lkml/?q=riscv+smcdeleg+ssccfg

[atish patra]

On Tue, Jun 18, 2024 at 2:21 AM Артемий Шушкин <atoma...@gmail.com> wrote:

I use my perf utility, which makes a call to perf event open according to the example in the documentation https://man7.org/linux/man-pages/man2/perf_event_open.2.html. Next, the PMU driver is contacted. The riscv_pmu_add function is called, in which we access the riscv_pmu_start function, where we set the period and get the init val (it is 2^63), after which opensbi is called, which writes this init val in the mcycle. Then the utility itself works correctly and outputs more or less correct values, but after it works, the mcycle becomes approximately 2^63, I use GDB, in which I am running Linux version (6.4.0). GDB shows normal register values before using the utility, and then broken ones. I also noticed that when loading Linux, it writes “Perf sampling/filtering is not supported as sscof extension is not available.” Could the absence of this extension somehow affect this problem?

No. That doesn't have any effect. It simply indicates that you can't use the perf record option.

 

I cannot understand why it is necessary to write 2^63 during initialization, and then, as far as I understand, not return the previous value.

The driver writes to a value during initialization so that the delta can be computed easily. The perf driver framework computes the delta and updates the value. 

There is no guarantee that what was the previous value and just incrementing the counter may result in overflow. That's why initialization is necessary.

I am not sure what is your use case but you can't mix n match while reading cycle counter via perf and direct read. If you are using perf tool, you should rely on it

to get you the correct count. 

 

вторник, 18 июня 2024 г. в 04:14:37 UTC+3, atis...@gmail.com:

Is it a direct read from user space or via perf tool ?

On Monday, June 17, 2024 at 2:17:10 PM UTC-7 tommy_...@hotmail.com wrote:

You'd probably need to provide more context info in order to get any useful feedback. E.g. what Linux kernel version, what distro, what RISC-V target implementation, how exactly you are performing your profiling test etc.

Perhaps it would be worth raising the issue in the context of the RISC-V Performance Analysis Tools SIG:

* https://lists.riscv.org/g/tech-announce/topic/announcing_the_formation_of_a/90476927

and/or the LKML?

* https://lkml.org/

--

Regards,

Atish