From: kan.liang@linux.intel.com
To: peterz@infradead.org, mingo@kernel.org, acme@kernel.org,
namhyung@kernel.org, irogers@google.com, adrian.hunter@intel.com,
alexander.shishkin@linux.intel.com, linux-kernel@vger.kernel.org
Cc: ak@linux.intel.com, eranian@google.com,
Kan Liang <kan.liang@linux.intel.com>
Subject: [RESEND PATCH 10/12] perf/x86/intel: Move PEBS event update after the sample output
Date: Tue, 18 Jun 2024 08:10:42 -0700 [thread overview]
Message-ID: <20240618151044.1318612-11-kan.liang@linux.intel.com> (raw)
In-Reply-To: <20240618151044.1318612-1-kan.liang@linux.intel.com>
From: Kan Liang <kan.liang@linux.intel.com>
In the drain_pebs(), besides outputting the sample data, the perf needs
to update the PEBS event (e.g., prev_count, event->count, etc.) as well.
Both operations may invoke the perf_event_update(), but the sequence of
the two operations doesn't matter for now. Because the updated event
value is read directly from the counter via rdpmc. The counter stops in
the drain_pebs().
But if the updated event value is from different places (PEBS record VS.
counter), the sequence does matter. For example, with the new Intel PEBS
counters snapshotting feature, the large PEBS can be enabled for the
sample read, since counter values for each sample are recorded in PEBS
records. The current perf does the PEBS event update first, which also
updates the event for all the records altogether. It's impossible for
the later sample read output to dump the value for each sample, since
the prev_count is already the newest one from the current counter.
Move PEBS event update after the sample output. For each sample read
output, it will update and output the value only for this sample
(according to the value in the PEBS record). Once all samples are
output, update the PEBS event again according to the current counter,
and set the left period.
The !intel_pmu_save_and_restart() only happens when !hwc->event_base
or the left > 0. The !hwc->event_base is impossible for the PEBS event
which is only available on GP and fixed counters.
The __intel_pmu_pebs_event() is only to process the overflowed sample.
The left should be always <=0.
It's safe to ignore the return from the !inel_pmu_save_and_restart()
check.
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
---
arch/x86/events/intel/ds.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index abf2b1991bc0..583fed8891b6 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -2158,17 +2158,6 @@ __intel_pmu_pebs_event(struct perf_event *event,
void *at = get_next_pebs_record_by_bit(base, top, bit);
static struct pt_regs dummy_iregs;
- if (hwc->flags & PERF_X86_EVENT_AUTO_RELOAD) {
- /*
- * Now, auto-reload is only enabled in fixed period mode.
- * The reload value is always hwc->sample_period.
- * May need to change it, if auto-reload is enabled in
- * freq mode later.
- */
- intel_pmu_save_and_restart_reload(event, count);
- } else if (!intel_pmu_save_and_restart(event))
- return;
-
if (!iregs)
iregs = &dummy_iregs;
@@ -2197,6 +2186,17 @@ __intel_pmu_pebs_event(struct perf_event *event,
if (perf_event_overflow(event, data, regs))
x86_pmu_stop(event, 0);
}
+
+ if (hwc->flags & PERF_X86_EVENT_AUTO_RELOAD) {
+ /*
+ * Now, auto-reload is only enabled in fixed period mode.
+ * The reload value is always hwc->sample_period.
+ * May need to change it, if auto-reload is enabled in
+ * freq mode later.
+ */
+ intel_pmu_save_and_restart_reload(event, count);
+ } else
+ intel_pmu_save_and_restart(event);
}
static void intel_pmu_drain_pebs_core(struct pt_regs *iregs, struct perf_sample_data *data)
--
2.35.1
next prev parent reply other threads:[~2024-06-18 15:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 15:10 [RESEND PATCH 00/12] Support Lunar Lake and Arrow Lake core PMU kan.liang
2024-06-18 15:10 ` [RESEND PATCH 01/12] perf/x86/intel: Support the PEBS event mask kan.liang
2024-06-20 7:02 ` Peter Zijlstra
2024-06-20 15:58 ` Liang, Kan
2024-06-21 14:19 ` Liang, Kan
2024-06-24 8:29 ` Peter Zijlstra
2024-06-24 8:21 ` Peter Zijlstra
2024-06-18 15:10 ` [RESEND PATCH 02/12] perf/x86: Support counter mask kan.liang
2024-06-20 7:06 ` Peter Zijlstra
2024-06-20 16:02 ` Liang, Kan
2024-06-18 15:10 ` [RESEND PATCH 03/12] perf/x86: Add Lunar Lake and Arrow Lake support kan.liang
2024-06-18 15:10 ` [RESEND PATCH 04/12] perf/x86/intel: Support new data source for Lunar Lake kan.liang
2024-06-20 7:34 ` Peter Zijlstra
2024-06-20 16:09 ` Liang, Kan
2024-06-18 15:10 ` [RESEND PATCH 05/12] perf/x86: Add config_mask to represent EVENTSEL bitmask kan.liang
2024-06-20 7:44 ` Peter Zijlstra
2024-06-20 16:16 ` Liang, Kan
2024-06-21 18:34 ` Liang, Kan
2024-06-24 8:28 ` Peter Zijlstra
2024-06-24 15:36 ` Liang, Kan
2024-06-24 8:26 ` Peter Zijlstra
2024-06-18 15:10 ` [RESEND PATCH 06/12] perf/x86/intel: Support PERFEVTSEL extension kan.liang
2024-06-18 15:10 ` [RESEND PATCH 07/12] perf/x86/intel: Support Perfmon MSRs aliasing kan.liang
2024-06-20 8:02 ` Peter Zijlstra
2024-06-20 16:17 ` Liang, Kan
2024-06-18 15:10 ` [RESEND PATCH 08/12] perf/x86: Extend event update interface kan.liang
2024-06-20 8:38 ` Peter Zijlstra
2024-06-20 16:18 ` Liang, Kan
2024-06-18 15:10 ` [RESEND PATCH 09/12] perf: Extend perf_output_read kan.liang
2024-06-20 9:00 ` Peter Zijlstra
2024-06-20 10:01 ` Peter Zijlstra
2024-06-18 15:10 ` kan.liang [this message]
2024-06-18 15:10 ` [RESEND PATCH 11/12] perf/x86/intel: Support PEBS counters snapshotting kan.liang
2024-06-18 15:10 ` [RESEND PATCH 12/12] perf/x86/intel: Support RDPMC metrics clear mode 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=20240618151044.1318612-11-kan.liang@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=eranian@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox