From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@linux.intel.com
Cc: 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,
ak@linux.intel.com, eranian@google.com
Subject: Re: [RESEND PATCH 09/12] perf: Extend perf_output_read
Date: Thu, 20 Jun 2024 12:01:55 +0200 [thread overview]
Message-ID: <20240620100155.GU12673@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20240620090028.GW31592@noisy.programming.kicks-ass.net>
On Thu, Jun 20, 2024 at 11:00:28AM +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2024 at 08:10:41AM -0700, kan.liang@linux.intel.com wrote:
> > From: Kan Liang <kan.liang@linux.intel.com>
> >
> > The event may have been updated in the PMU-specific implementation,
> > e.g., Intel PEBS counters snapshotting. The common code should not
> > read and overwrite the value.
> >
> > The PERF_SAMPLE_READ in the data->sample_type can be used to detect
> > whether the PMU-specific value is available. If yes, avoid the
> > pmu->read() in the common code.
> >
> > Reviewed-by: Andi Kleen <ak@linux.intel.com>
> > Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> > ---
> > kernel/events/core.c | 15 ++++++++-------
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 8f908f077935..733e507948e6 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -7243,7 +7243,7 @@ static void perf_output_read_one(struct perf_output_handle *handle,
> >
> > static void perf_output_read_group(struct perf_output_handle *handle,
> > struct perf_event *event,
> > - u64 enabled, u64 running)
> > + u64 enabled, u64 running, bool read)
> > {
> > struct perf_event *leader = event->group_leader, *sub;
> > u64 read_format = event->attr.read_format;
> > @@ -7265,7 +7265,7 @@ static void perf_output_read_group(struct perf_output_handle *handle,
> > if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING)
> > values[n++] = running;
> >
> > - if ((leader != event) &&
> > + if ((leader != event) && read &&
> > (leader->state == PERF_EVENT_STATE_ACTIVE))
> > leader->pmu->read(leader);
> >
> > @@ -7280,7 +7280,7 @@ static void perf_output_read_group(struct perf_output_handle *handle,
> > for_each_sibling_event(sub, leader) {
> > n = 0;
> >
> > - if ((sub != event) &&
> > + if ((sub != event) && read &&
> > (sub->state == PERF_EVENT_STATE_ACTIVE))
> > sub->pmu->read(sub);
> >
> > @@ -7307,7 +7307,8 @@ static void perf_output_read_group(struct perf_output_handle *handle,
> > * on another CPU, from interrupt/NMI context.
> > */
> > static void perf_output_read(struct perf_output_handle *handle,
> > - struct perf_event *event)
> > + struct perf_event *event,
> > + bool read)
> > {
> > u64 enabled = 0, running = 0, now;
> > u64 read_format = event->attr.read_format;
> > @@ -7325,7 +7326,7 @@ static void perf_output_read(struct perf_output_handle *handle,
> > calc_timer_values(event, &now, &enabled, &running);
> >
> > if (event->attr.read_format & PERF_FORMAT_GROUP)
> > - perf_output_read_group(handle, event, enabled, running);
> > + perf_output_read_group(handle, event, enabled, running, read);
> > else
> > perf_output_read_one(handle, event, enabled, running);
> > }
> > @@ -7367,7 +7368,7 @@ void perf_output_sample(struct perf_output_handle *handle,
> > perf_output_put(handle, data->period);
> >
> > if (sample_type & PERF_SAMPLE_READ)
> > - perf_output_read(handle, event);
> > + perf_output_read(handle, event, !(data->sample_flags & PERF_SAMPLE_READ));
> >
> > if (sample_type & PERF_SAMPLE_CALLCHAIN) {
> > int size = 1;
>
> this can't be right. The output is order sensitive. If a
> PERF_SAMPLE_READ is part of the PERF_RECORD_SAMPLE, it must be in this
> location.
Oh, n/n. I read that wrong. I'll try again after a break.
next prev parent reply other threads:[~2024-06-20 10:02 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 [this message]
2024-06-18 15:10 ` [RESEND PATCH 10/12] perf/x86/intel: Move PEBS event update after the sample output kan.liang
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=20240620100155.GU12673@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--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=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@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 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.