From: "tip-bot2 for Kan Liang" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Kan Liang <kan.liang@linux.intel.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
stable@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: [tip: perf/core] perf/x86/intel/ds: Unconditionally drain PEBS DS when changing PEBS_DATA_CFG
Date: Mon, 02 Dec 2024 11:14:22 -0000 [thread overview]
Message-ID: <173313806215.412.18103414401551662348.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20241119135504.1463839-2-kan.liang@linux.intel.com>
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 9f3de72a0c37005f897d69e4bdd59c25b8898447
Gitweb: https://git.kernel.org/tip/9f3de72a0c37005f897d69e4bdd59c25b8898447
Author: Kan Liang <kan.liang@linux.intel.com>
AuthorDate: Tue, 19 Nov 2024 05:55:01 -08:00
Committer: Peter Zijlstra <peterz@infradead.org>
CommitterDate: Mon, 02 Dec 2024 12:01:33 +01:00
perf/x86/intel/ds: Unconditionally drain PEBS DS when changing PEBS_DATA_CFG
The PEBS kernel warnings can still be observed with the below case.
when the below commands are running in parallel for a while.
while true;
do
perf record --no-buildid -a --intr-regs=AX \
-e cpu/event=0xd0,umask=0x81/pp \
-c 10003 -o /dev/null ./triad;
done &
while true;
do
perf record -e 'cpu/mem-loads,ldlat=3/uP' -W -d -- ./dtlb
done
The commit b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing
PEBS_DATA_CFG") intends to flush the entire PEBS buffer before the
hardware is reprogrammed. However, it fails in the above case.
The first perf command utilizes the large PEBS, while the second perf
command only utilizes a single PEBS. When the second perf event is
added, only the n_pebs++. The intel_pmu_pebs_enable() is invoked after
intel_pmu_pebs_add(). So the cpuc->n_pebs == cpuc->n_large_pebs check in
the intel_pmu_drain_large_pebs() fails. The PEBS DS is not flushed.
The new PEBS event should not be taken into account when flushing the
existing PEBS DS.
The check is unnecessary here. Before the hardware is reprogrammed, all
the stale records must be drained unconditionally.
For single PEBS or PEBS-vi-pt, the DS must be empty. The drain_pebs()
can handle the empty case. There is no harm to unconditionally drain the
PEBS DS.
Fixes: b752ea0c28e3 ("perf/x86/intel/ds: Flush PEBS DS when changing PEBS_DATA_CFG")
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20241119135504.1463839-2-kan.liang@linux.intel.com
---
arch/x86/events/intel/ds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 8afc4ad..1a4b326 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -1489,7 +1489,7 @@ void intel_pmu_pebs_enable(struct perf_event *event)
* hence we need to drain when changing said
* size.
*/
- intel_pmu_drain_large_pebs(cpuc);
+ intel_pmu_drain_pebs_buffer();
adaptive_pebs_record_size_update();
wrmsrl(MSR_PEBS_DATA_CFG, pebs_data_cfg);
cpuc->active_pebs_data_cfg = pebs_data_cfg;
next prev parent reply other threads:[~2024-12-02 11:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-19 13:55 [PATCH V2 0/4] PEBS DS bug fix and optimization kan.liang
2024-11-19 13:55 ` [PATCH V2 1/4] perf/x86/intel/ds: Unconditionally drain PEBS DS when changing PEBS_DATA_CFG kan.liang
2024-12-02 11:14 ` tip-bot2 for Kan Liang [this message]
2024-11-19 13:55 ` [PATCH V2 2/4] perf/x86/intel/ds: Clarify adaptive PEBS processing kan.liang
2024-12-02 11:14 ` [tip: perf/core] " tip-bot2 for Kan Liang
2024-11-19 13:55 ` [PATCH V2 3/4] perf/x86/intel/ds: Factor out functions for PEBS records processing kan.liang
2024-12-02 11:14 ` [tip: perf/core] " tip-bot2 for Kan Liang
2024-11-19 13:55 ` [PATCH V2 4/4] perf/x86/intel/ds: Simplify the PEBS records processing for adaptive PEBS kan.liang
2024-12-02 11:14 ` [tip: perf/core] " tip-bot2 for Kan Liang
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=173313806215.412.18103414401551662348.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=x86@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
all inboxes | Powered by JetHome®