Re: [PATCH v2 3/9] perf/cxl: Fix the counter overflow delta fixup

Dave Jiang <[email protected]> Thu, 30 Jul 2026 10:19:47 -0700
Newsgroups org.kernel.vger.linux-cxl,org.kernel.vger.linux-perf-users
Message-ID <[email protected]>

On 7/30/26 9:56 AM, Dave Jiang wrote:
> 
> 
> On 7/29/26 3:21 PM, Jonathan Cameron wrote:
>> On Wed, 29 Jul 2026 07:55:49 -0700
>> Dave Jiang <[email protected]> wrote:
>>
>>> Counters are configured with Freeze on Overflow and are never reloaded: on
>>> overflow the counter wraps to 0, counts on until the CPMU freezes, and
>> Hi Dave,
>>
>> Thanks for looking at these.
>>
>> Why would it count on if it froze?  I think the bot is tripping over the
>> fact we don't yet implement free running counters (and the other bug
>> about not unfreezing) for currently the ability to freeze on only some
>> counters (to do periodic sampling for instance).
>>
>> The CXL CPMU spec is incredibly broad in what is supported, so maybe
>> we want to harden things anyway but I'm not sure the condition described
>> by most of this is real.
>>
>>> retains that residual (CXL r4.0 8.2.7.2.3). So the masked subtraction in
>>> __cxl_pmu_read() only spans the wrap when new_cnt < prev_cnt.
>>
>> It's been a long time so maybe I have how this was meant to work wrong.
>>
>> There are two paths to __cxl_pmu_read()
>>
>> 1. We have freeze on overflow enabled so any counter that overflows results
>> in an interrupt. At that point all counters are frozen.
>> We then read only the counter that overflowed (which is 0) and that
>> will update the prev_cnt storage.  No chance of hitting the full wrap
>> around seen here.
>>
>> 2. An on demand read (polling) In this case the counter may
>> take any value, but because we have freeze on overflow it can't have
>> wrapped (as otherwise we'd have taken path 1).
>>
>> So slightly fun question of why we have any wrapping control and I think
>> the answer is because the freeze on overflow isn't very specific in the
>> spec for whether it freezes on max value or 0.
> 
> Vague enough that hardware can freeze on overflow but leave greater than 0 value? Or is it always either max value or 0? If you don't think this patch is needed I can drop.

Actually the spec does defines it to be 0 on overflow (8.2.7.2.3). Although there isn't clear language that indicates with the freeze, if any chance of any additional events being counted before freeze take effect.