Linux Perf Users
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-cxl@vger.kernel.org, linux-perf-users@vger.kernel.org,
	will@kernel.org, mark.rutland@arm.com, dave@stgolabs.net,
	sashiko-bot@kernel.org
Subject: Re: [PATCH v2 3/9] perf/cxl: Fix the counter overflow delta fixup
Date: Thu, 30 Jul 2026 10:19:47 -0700	[thread overview]
Message-ID: <fd6701db-82b7-4a94-a223-b0d051035dc7@intel.com> (raw)
In-Reply-To: <51728f3b-e75d-4b63-a355-7d0b0398d0dc@intel.com>



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 <dave.jiang@intel.com> 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.



  reply	other threads:[~2026-07-30 17:19 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29 14:55 [PATCH v2 0/9] perf/cxlpmu: Misc sashiko raised issues fixes Dave Jiang
2026-07-29 14:55 ` [PATCH v2 1/9] perf/cxl: Program the requested event group on configurable counters Dave Jiang
2026-07-29 15:06   ` sashiko-bot
2026-07-29 22:29   ` Jonathan Cameron
2026-07-30 15:50     ` Dave Jiang
2026-07-29 14:55 ` [PATCH v2 2/9] perf/cxl: Clear stale event fields before reprogramming a counter Dave Jiang
2026-07-29 15:08   ` sashiko-bot
2026-07-29 22:25   ` Jonathan Cameron
2026-07-30 15:45     ` Dave Jiang
2026-07-29 14:55 ` [PATCH v2 3/9] perf/cxl: Fix the counter overflow delta fixup Dave Jiang
2026-07-29 15:13   ` sashiko-bot
2026-07-29 22:21   ` Jonathan Cameron
2026-07-30 16:56     ` Dave Jiang
2026-07-30 17:19       ` Dave Jiang [this message]
2026-07-30 19:00       ` Jonathan Cameron
2026-07-29 14:55 ` [PATCH v2 4/9] perf/cxl: Accept an overflow interrupt on MSI message number 0 Dave Jiang
2026-07-29 19:28   ` Jonathan Cameron
2026-07-29 19:59   ` Davidlohr Bueso
2026-07-30 12:18   ` Robin Murphy
2026-07-30 17:57     ` Dave Jiang
2026-07-30 18:57     ` Jonathan Cameron
2026-07-30 21:32       ` Dave Jiang
2026-07-29 14:55 ` [PATCH v2 5/9] perf/cxl: Keep the overflow interrupt pinned to the managed CPU Dave Jiang
2026-07-29 15:23   ` sashiko-bot
2026-07-29 19:25   ` Jonathan Cameron
2026-07-29 20:27   ` Davidlohr Bueso
2026-07-30 11:46   ` Robin Murphy
2026-07-30 18:55     ` Jonathan Cameron
2026-07-30 21:34       ` Dave Jiang
2026-07-30 22:19     ` Dave Jiang
2026-07-29 14:55 ` [PATCH v2 6/9] perf/cxl: Unfreeze counters after handling an overflow interrupt Dave Jiang
2026-07-29 19:24   ` Jonathan Cameron
2026-07-30 12:04   ` Robin Murphy
2026-07-30 18:53     ` Jonathan Cameron
2026-07-30 23:00       ` Dave Jiang
2026-07-29 14:55 ` [PATCH v2 7/9] perf/cxl: Validate the hardware-reported counter width Dave Jiang
2026-07-29 15:11   ` sashiko-bot
2026-07-29 19:21   ` Jonathan Cameron
2026-07-29 14:55 ` [PATCH v2 8/9] perf/cxl: Don't use pmu.dev in IRQ and hotplug callbacks after unregister Dave Jiang
2026-07-29 15:34   ` sashiko-bot
2026-07-29 19:17   ` Jonathan Cameron
2026-07-30 11:38   ` Robin Murphy
2026-07-30 18:51     ` Jonathan Cameron
2026-07-29 14:55 ` [PATCH v2 9/9] perf/cxl: Avoid cpumask_of(-1) when no CPU is assigned Dave Jiang
2026-07-29 15:19   ` sashiko-bot
2026-07-29 19:14   ` Jonathan Cameron
2026-07-30  9:36     ` Robin Murphy
2026-07-31  0:11     ` Dave Jiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fd6701db-82b7-4a94-a223-b0d051035dc7@intel.com \
    --to=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=jic23@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sashiko-bot@kernel.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox