Linux Perf Users
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: sashiko@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [Patch v4 2/5] perf/x86/intel: Always reprogram ACR events to prevent stale masks
Date: Thu, 30 Apr 2026 11:02:24 +0800	[thread overview]
Message-ID: <b97fb2be-fa3a-42d9-9aa6-e87afc85a6a9@linux.intel.com> (raw)
In-Reply-To: <20260430020402.60C32C19425@smtp.kernel.org>


On 4/30/2026 10:04 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Unconditional hardware MSR reprogramming for ACR events introduces performance regression and increases measurement blind spots.
> --
>
> commit a8f30026401c4d7de00c3f1a7543204056d7235c
> Author: Dapeng Mi <dapeng1.mi@linux.intel.com>
> perf/x86/intel: Always reprogram ACR events to prevent stale masks
>
> This commit modifies PMU event scheduling to force reprogramming of all ACR
> events during rescheduling. It does this by making match_prev_assignment()
> always return false for ACR events.
>
>> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
>> index 810ab21ffd99..4b9e105309c6 100644
>> --- a/arch/x86/events/core.c
>> +++ b/arch/x86/events/core.c
>> @@ -1294,13 +1294,16 @@ int x86_perf_rdpmc_index(struct perf_event *event)
>>  	return event->hw.event_base_rdpmc;
>>  }
>>  
>> -static inline int match_prev_assignment(struct hw_perf_event *hwc,
>> +static inline int match_prev_assignment(struct perf_event *event,
>>  					struct cpu_hw_events *cpuc,
>>  					int i)
>>  {
>> +	struct hw_perf_event *hwc = &event->hw;
>> +
>>  	return hwc->idx == cpuc->assign[i] &&
>> -		hwc->last_cpu == smp_processor_id() &&
>> -		hwc->last_tag == cpuc->tags[i];
>> +	       hwc->last_cpu == smp_processor_id() &&
>> +	       hwc->last_tag == cpuc->tags[i] &&
>> +	       !is_acr_event_group(event);
>>  }
> Does this unconditional hardware MSR reprogramming for ACR events introduce a
> performance regression and increase measurement blind spots?
>
> By unconditionally returning false for all ACR events, every active ACR event
> will undergo a full x86_pmu_stop() and x86_pmu_start() cycle during PMU
> re-enablement (e.g., in x86_pmu_enable() when cpuc->n_added > 0).
>
> These full stop/start cycles invoke multiple wrmsr and rdpmc instructions,
> adding significant cycle overhead to the hot scheduling path. Since this
> occurs while the PMU is globally disabled, the added latency extends the
> global PMU off-time, unnecessarily increasing the measurement blind spot
> where events are not counted across the CPU.
>
> Could this overhead be avoided by checking if the mask actually changed?
>
> x86_pmu_late_setup() calculates the new physical mask and stores it in
> event->hw.config1 before match_prev_assignment() is evaluated. Would it be
> better to compare event->hw.config1 against the previously programmed mask
> stored in cpuc->acr_cfg_b[hwc->idx] and only force a reprogram when they
> differ?

Nice idea. This can be further optimized. I'm not sure if it's worth to
post a new patchset for this single optimization.  If not, I would post a
single optimization patch for this.

Thanks.


>
> [ ... ]
>

  reply	other threads:[~2026-04-30  3:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30  0:25 [Patch v4 0/5] perf/x86/intel: Fix bugs of auto counter reload sampling Dapeng Mi
2026-04-30  0:25 ` [Patch v4 1/5] perf/x86/intel: Improve validation and configuration of ACR masks Dapeng Mi
2026-04-30  0:25 ` [Patch v4 2/5] perf/x86/intel: Always reprogram ACR events to prevent stale masks Dapeng Mi
2026-04-30  2:04   ` sashiko-bot
2026-04-30  3:02     ` Mi, Dapeng [this message]
2026-04-30  0:25 ` [Patch v4 3/5] perf/x86/intel: Disable PMI for self-reloaded ACR events Dapeng Mi
2026-04-30  2:36   ` sashiko-bot
2026-04-30  6:33     ` Mi, Dapeng
2026-04-30  0:25 ` [Patch v4 4/5] perf/x86/intel: Enable auto counter reload for DMR Dapeng Mi
2026-04-30  0:25 ` [Patch v4 5/5] perf/x86/intel: Consolidate MSR_IA32_PERF_CFG_C tracking Dapeng Mi

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=b97fb2be-fa3a-42d9-9aa6-e87afc85a6a9@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko@lists.linux.dev \
    /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