From: Dapeng Mi <dapeng1.mi@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
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>
Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Dapeng Mi <dapeng1.mi@intel.com>, Zide Chen <zide.chen@intel.com>,
Falcon Thomas <thomas.falcon@intel.com>,
Xudong Hao <xudong.hao@intel.com>,
Dapeng Mi <dapeng1.mi@linux.intel.com>
Subject: [PATCH 02/12] perf/x86/intel: Fix CMT PEBS load/store direction for latency events
Date: Thu, 17 Sep 2026 09:52:24 +0800 [thread overview]
Message-ID: <20260917015234.981153-3-dapeng1.mi@linux.intel.com> (raw)
In-Reply-To: <20260917015234.981153-1-dapeng1.mi@linux.intel.com>
Same issue exists on Crestmont, intel_cmt_pebs_event_constraints[]
applies LAT_CONSTRAINT constraints to
MEM_UOPS_RETIRED.{LOAD,STORE}_LATENCY, but does not set explicit
LOAD/STORE flags for those events.
The PEBS latency path (pebs_latency_data(), via cmt_latency_data) uses
the event flags to determine memory operation direction. Without an
explicit STORE flag, samples from MEM_UOPS_RETIRED.STORE_LATENCY can be
misclassified as LOADs.
Set explicit LOAD/STORE flags in intel_cmt_pebs_event_constraints[] for:
- MEM_UOPS_RETIRED.LOAD_LATENCY
- MEM_UOPS_RETIRED.STORE_LATENCY
This fixes incorrect STORE sample classification.
Fixes: e99fb45436ea ("perf/x86/intel: Update event constraints and cache_extra_regsfor MTL")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
arch/x86/events/intel/ds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 20674871c6c3..434adf15d83c 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1305,8 +1305,8 @@ struct event_constraint intel_grt_pebs_event_constraints[] = {
struct event_constraint intel_cmt_pebs_event_constraints[] = {
/* Allow all events as PEBS with no flags */
- INTEL_HYBRID_LAT_CONSTRAINT(0x5d0, 0x3),
- INTEL_HYBRID_LAT_CONSTRAINT(0x6d0, 0xff),
+ INTEL_HYBRID_LDLAT_CONSTRAINT(0x5d0, 0x3),
+ INTEL_HYBRID_STLAT_CONSTRAINT(0x6d0, 0xff),
EVENT_CONSTRAINT_END
};
--
2.34.1
next prev parent reply other threads:[~2026-09-17 1:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 1:52 [PATCH 00/12] perf/x86/intel: PEBS data-source fixes and OMR updates Dapeng Mi
2026-09-17 1:52 ` [PATCH 01/12] perf/x86/intel: Fix GRT PEBS load/store direction for latency events Dapeng Mi
2026-09-17 2:14 ` sashiko-bot
2026-09-17 1:52 ` Dapeng Mi [this message]
2026-09-17 2:08 ` [PATCH 02/12] perf/x86/intel: Fix CMT " sashiko-bot
2026-09-17 1:52 ` [PATCH 03/12] perf/x86/intel: Fix DKT " Dapeng Mi
2026-09-17 2:09 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 04/12] perf/x86/intel: Update arw_latency_data() mem-op direction handling Dapeng Mi
2026-09-17 2:21 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 05/12] perf/x86/intel: Remove incorrect LionCove PEBS data-source constraints Dapeng Mi
2026-09-17 2:10 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 06/12] perf/x86/intel: Remove incorrect PantherCove " Dapeng Mi
2026-09-17 2:10 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 07/12] perf/x86/intel: Correct Panther cove data source snoop states Dapeng Mi
2026-09-17 2:05 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 08/12] perf/x86/intel: Delete dead NVL PEBS data-source init call Dapeng Mi
2026-09-17 2:11 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 09/12] perf/x86/intel: Constrain PantherCove UOPS_DISPATCHED events Dapeng Mi
2026-09-17 2:03 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 10/12] perf/x86/intel: Add precise OMR event support for DMR/NVL Dapeng Mi
2026-09-17 2:11 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 11/12] perf/x86/intel: Rename DMR offcore_rsp attribute to offmodule_rsp Dapeng Mi
2026-09-17 2:11 ` sashiko-bot
2026-09-17 1:52 ` [PATCH 12/12] perf/x86/intel: Rename NVL " Dapeng Mi
2026-09-17 2:14 ` sashiko-bot
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=20260917015234.981153-3-dapeng1.mi@linux.intel.com \
--to=dapeng1.mi@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=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 \
--cc=thomas.falcon@intel.com \
--cc=xudong.hao@intel.com \
--cc=zide.chen@intel.com \
/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.