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.