Re: [PATCH v8 00/21] ARM64 PMU Partitioning

[Colton Lewis <coltonlewis@google.com>]

James Clark <james.clark@linaro.org> writes:

> On 23/07/2026 9:57 pm, Colton Lewis wrote:
>> James Clark <james.clark@linaro.org> writes:
>>>>> When running the guest on a single CPU I get different counts for the
>>>>> same event for a single process, although this never happens on a  
>>>>> host.
>>>>> I think there might even be some Perf tests which expect them to be  
>>>>> the
>>>>> same, and this doesn't depend on whether any events are running on the
>>>>> host or not. Not sure if you ran all the Perf selftests in a guest or
>>>>> not?

>>>> I'll investigate but I'm not sure perf is intended to guarantee
>>>> that. perf stat just runs the event counters but may not write or read
>>>> them at exactly the same time.


>>> Is that true? The perf core calls perf_pmu_disable() when a process is
>>> scheduled out before reading the count of each event of that process in
>>> an inner loop. The perf_pmu_disable() clears PMCR_EL0.E which freezes
>>> all of the counters so they can be read out in a consistent state.

>>> It's important that they're all stopped at the same time because
>>> counters might be used in metrics as ratios of each other. So I think
>>> it's deliberately designed that way and appears to not be working in a
>>> guest now.

>> By default I think perf assumes events can be measured independently, If
>> you want to guarantee events are scheduled together to avoid measurement
>> skew you need to make sure the events are grouped.

>> The common way to do that is with {} around the event list:

>> perf stat -e {branches,branches}

>> Please see if that resolves the issue.


> Groups only change how the events are scheduled, not how the driver
> starts or stops multiple events running on the same PMU (grouped or
> ungrouped). In my repro I had less events than counters in HW, so they
> will always be scheduled at the same time regardless of grouping.

> I did notice something extra though, you have to first open some amount
> of counters, and then open more than that. Then the second time the ones
> with different counts will be however many were opened first time, as if
> some state has stuck.

> For example if I open two counters then 6, the first two always have
> different counts the second time:

>     $ perf stat -e branches,branches true

>     Performance counter stats for 'true':

>               106129      branches

>               106129      branches



>     $ perf stat -e
> '{branches,branches,branches,branches,branches,branches}' true

>     Performance counter stats for 'true':

>               117013      branches

>               117013      branches

>               110364      branches

>               110364      branches

>               110364      branches

>               110364      branches


> After opening 6 again a third time they'll all have the same counts.

Interesting. Thanks. To clarify, is this happening in the host or VM?