From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dapeng Mi <dapeng1.mi@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
Eranian Stephane <eranian@google.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [Patch v3 12/22] perf/x86/intel: Update dyn_constranit base on PEBS event precise level
Date: Wed, 16 Apr 2025 15:45:24 -0400 [thread overview]
Message-ID: <e0b25b3e-aec0-4c43-9ab2-907186b56c71@linux.intel.com> (raw)
In-Reply-To: <20250416153226.GC17910@noisy.programming.kicks-ass.net>
On 2025-04-16 11:32 a.m., Peter Zijlstra wrote:
> On Tue, Apr 15, 2025 at 12:31:03PM -0400, Liang, Kan wrote:
>
>>> This can land us in EVENT_CONSTRAINT_OVERLAP territory, no?
>
>> The dyn_constraint is a supplement of the static constraints. It doesn't
>> overwrite the static constraints.
>
> That doesn't matter.
>
>> In the intel_get_event_constraints(), perf always gets the static
>> constraints first. If the dyn_constraint is defined, it gets the common
>> mask of the static constraints and the dynamic constraints. All
>> constraint rules will be complied.
>>
>> if (event->hw.dyn_constraint != ~0ULL) {
>> c2 = dyn_constraint(cpuc, c2, idx);
>> c2->idxmsk64 &= event->hw.dyn_constraint;
>> c2->weight = hweight64(c2->idxmsk64);
>> }
>
> Read the comment that goes with EVENT_CONSTRAINT_OVERLAP().
>
> Suppose we have (from intel_lnc_event_constraints[]):
>
> INTEL_UEVENT_CONSTRAINT(0x012a, 0xf)
> INTEL_EVENT_CONSTRAINT(0x2e, 0x3ff)
>
> Then since the first is fully contained in the latter, there is no
> problem.
>
> Now imagine PEBS gets a dynamic constraint of 0x3c (just because), and
> then you try and create a PEBS event along with the above two events,
> and all of a sudden you have:
>
> 0x000f
> 0x003c
> 0x03ff
>
> And that is exactly the problem case.
>
> Also, looking at that LNC table, please explain:
>
> INTEL_UEVENT_CONSTRAINT(0x01cd, 0x3fc)
>
> that looks like the exact thing I've asked to never do, exactly because
> of the above problem :-(
I see. I think we can check the constraint table and update the overlap
bit accordingly. Similar to what we did in the
intel_pmu_check_event_constraints() for the fixed counters.
I'm thinking something as below (Just a POC, not tested.)
For the static table, set the overlap for the events that may trigger
the issue at init time.
For the dynamic constraint, add a dyn_overlap_mask to track if overlap
is required for the feature (The below only supports the branch
counters. The ACR and ARCH PEBS can be added later.) If it's required,
set a flag PERF_X86_EVENT_OVERLAP for the event when the dyn_constraint
is applied. The overlap bit will be set at runtime.
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 16f8aea33243..76a03a0c28e9 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3825,6 +3825,8 @@ intel_get_event_constraints(struct cpu_hw_events
*cpuc, int idx,
c2 = dyn_constraint(cpuc, c2, idx);
c2->idxmsk64 &= event->hw.dyn_constraint;
c2->weight = hweight64(c2->idxmsk64);+ if (event->hw.flags &
PERF_X86_EVENT_OVERLAP)
+ c2->overlap = 1;
}
return c2;
@@ -4197,6 +4199,12 @@ static inline void
intel_pmu_set_acr_caused_constr(struct perf_event *event,
event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64);
}
+enum dyn_overlap_bits {
+ DYN_OVERLAP_BRANCH_CNTR
+};
+
+static unsigned long dyn_overlap_mask;
+
static int intel_pmu_hw_config(struct perf_event *event)
{
int ret = x86_pmu_hw_config(event);
@@ -4261,6 +4269,8 @@ static int intel_pmu_hw_config(struct perf_event
*event)
if (branch_sample_counters(leader)) {
num++;
leader->hw.dyn_constraint &= x86_pmu.lbr_counters;
+ if (test_bit(DYN_OVERLAP_BRANCH_CNTR, &dyn_overlap_mask);
+ leader->hw.flags |= PERF_X86_EVENT_OVERLAP;
}
leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS;
@@ -4270,6 +4280,8 @@ static int intel_pmu_hw_config(struct perf_event
*event)
if (branch_sample_counters(sibling)) {
num++;
sibling->hw.dyn_constraint &= x86_pmu.lbr_counters;
+ if (test_bit(DYN_OVERLAP_BRANCH_CNTR, &dyn_overlap_mask);
+ sibling->hw.flags |= PERF_X86_EVENT_OVERLAP;
}
}
@@ -6638,6 +6650,29 @@ static void
intel_pmu_check_event_constraints(struct event_constraint *event_con
if (!event_constraints)
return;
+ for_each_event_constraint(c, event_constraints) {
+ if (c->weight == 1 || c->overlap)
+ continue;
+
+ /*
+ * The counter mask of an event is not a subset of
+ * the counter mask of a constraint with an equal
+ * or higher weight. The overlap flag must be set.
+ */
+ for_each_event_constraint(c2, event_constraints) {
+ if ((c2->weight >= c->weight) &&
+ (c2->idxmsk64 | c->idxmsk64) != c2->idxmsk64) {
+ c->overlap = 1;
+ break;
+ }
+ }
+
+ /* Check for the dynamic constraint */
+ if (c->weight >= HWEIGHT(x86_pmu.lbr_counters) &&
+ (c->idxmsk64 | x86_pmu.lbr_counters) != c->idxmsk64)
+ __set_bit(DYN_OVERLAP_BRANCH_CNTR, &dyn_overlap_mask);
+ }
+
/*
* event on fixed counter2 (REF_CYCLES) only works on this
* counter, so do not extend mask to generic counters
Thanks,
Kan
next prev parent reply other threads:[~2025-04-16 19:45 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 11:44 [Patch v3 00/22] Arch-PEBS and PMU supports for Clearwater Forest and Panther Lake Dapeng Mi
2025-04-15 11:44 ` [Patch v3 01/22] perf/x86/intel: Add Panther Lake support Dapeng Mi
2025-04-17 13:01 ` [tip: perf/core] " tip-bot2 for Kan Liang
2025-04-15 11:44 ` [Patch v3 02/22] perf/x86/intel: Add PMU support for Clearwater Forest Dapeng Mi
2025-04-17 13:01 ` [tip: perf/core] " tip-bot2 for Dapeng Mi
2025-04-15 11:44 ` [Patch v3 03/22] perf/x86/intel: Parse CPUID archPerfmonExt leaves for non-hybrid CPUs Dapeng Mi
2025-04-17 13:01 ` [tip: perf/core] " tip-bot2 for Dapeng Mi
2025-04-15 11:44 ` [Patch v3 04/22] perf/x86/intel: Decouple BTS initialization from PEBS initialization Dapeng Mi
2025-04-17 13:01 ` [tip: perf/core] " tip-bot2 for Dapeng Mi
2025-04-15 11:44 ` [Patch v3 05/22] perf/x86/intel: Rename x86_pmu.pebs to x86_pmu.ds_pebs Dapeng Mi
2025-04-17 13:01 ` [tip: perf/core] " tip-bot2 for Dapeng Mi
2025-04-15 11:44 ` [Patch v3 06/22] perf/x86/intel: Introduce pairs of PEBS static calls Dapeng Mi
2025-04-17 13:00 ` [tip: perf/core] " tip-bot2 for Dapeng Mi
2025-04-15 11:44 ` [Patch v3 07/22] perf/x86/intel: Initialize architectural PEBS Dapeng Mi
2025-04-15 11:44 ` [Patch v3 08/22] perf/x86/intel/ds: Factor out PEBS record processing code to functions Dapeng Mi
2025-04-15 11:44 ` [Patch v3 09/22] perf/x86/intel/ds: Factor out PEBS group " Dapeng Mi
2025-04-15 11:44 ` [Patch v3 10/22] perf/x86/intel: Process arch-PEBS records or record fragments Dapeng Mi
2025-04-15 13:57 ` Peter Zijlstra
2025-04-15 16:09 ` Liang, Kan
2025-04-15 11:44 ` [Patch v3 11/22] perf/x86/intel: Allocate arch-PEBS buffer and initialize PEBS_BASE MSR Dapeng Mi
2025-04-15 13:45 ` Peter Zijlstra
2025-04-16 0:59 ` Mi, Dapeng
2025-04-15 13:48 ` Peter Zijlstra
2025-04-16 1:03 ` Mi, Dapeng
2025-04-15 11:44 ` [Patch v3 12/22] perf/x86/intel: Update dyn_constranit base on PEBS event precise level Dapeng Mi
2025-04-15 13:53 ` Peter Zijlstra
2025-04-15 16:31 ` Liang, Kan
2025-04-16 1:46 ` Mi, Dapeng
2025-04-16 13:59 ` Liang, Kan
2025-04-17 1:15 ` Mi, Dapeng
2025-04-16 15:32 ` Peter Zijlstra
2025-04-16 19:45 ` Liang, Kan [this message]
2025-04-16 19:56 ` Peter Zijlstra
2025-04-22 22:50 ` Liang, Kan
2025-04-15 11:44 ` [Patch v3 13/22] perf/x86/intel: Setup PEBS data configuration and enable legacy groups Dapeng Mi
2025-04-15 11:44 ` [Patch v3 14/22] perf/x86/intel: Add counter group support for arch-PEBS Dapeng Mi
2025-04-15 11:44 ` [Patch v3 15/22] perf/x86/intel: Support SSP register capturing " Dapeng Mi
2025-04-15 14:07 ` Peter Zijlstra
2025-04-16 5:49 ` Mi, Dapeng
2025-04-15 11:44 ` [Patch v3 16/22] perf/core: Support to capture higher width vector registers Dapeng Mi
2025-04-15 14:36 ` Peter Zijlstra
2025-04-16 6:42 ` Mi, Dapeng
2025-04-16 15:53 ` Peter Zijlstra
2025-04-17 2:00 ` Mi, Dapeng
2025-04-22 3:05 ` Mi, Dapeng
2025-04-15 11:44 ` [Patch v3 17/22] perf/x86/intel: Support arch-PEBS vector registers group capturing Dapeng Mi
2025-04-15 11:44 ` [Patch v3 18/22] perf tools: Support to show SSP register Dapeng Mi
2025-04-15 11:44 ` [Patch v3 19/22] perf tools: Enhance arch__intr/user_reg_mask() helpers Dapeng Mi
2025-04-15 11:44 ` [Patch v3 20/22] perf tools: Enhance sample_regs_user/intr to capture more registers Dapeng Mi
2025-04-15 11:44 ` [Patch v3 21/22] perf tools: Support to capture more vector registers (x86/Intel) Dapeng Mi
2025-04-15 11:44 ` [Patch v3 22/22] perf tools/tests: Add vector registers PEBS sampling test Dapeng Mi
2025-04-15 15:21 ` [Patch v3 00/22] Arch-PEBS and PMU supports for Clearwater Forest and Panther Lake Liang, Kan
2025-04-16 7:42 ` Peter Zijlstra
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=e0b25b3e-aec0-4c43-9ab2-907186b56c71@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dapeng1.mi@intel.com \
--cc=dapeng1.mi@linux.intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.