From: Ben Gainey <Ben.Gainey@arm.com>
To: "peterz@infradead.org" <peterz@infradead.org>
Cc: "alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mark Rutland <Mark.Rutland@arm.com>,
"acme@kernel.org" <acme@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
James Clark <James.Clark@arm.com>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"irogers@google.com" <irogers@google.com>,
"jolsa@kernel.org" <jolsa@kernel.org>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH v7 1/4] perf: Support PERF_SAMPLE_READ with inherit
Date: Fri, 7 Jun 2024 10:16:15 +0000 [thread overview]
Message-ID: <451afb8eb03f1519c482a84a6c1cbd1e62222988.camel@arm.com> (raw)
In-Reply-To: <20240607093254.GN8774@noisy.programming.kicks-ass.net>
On Fri, 2024-06-07 at 11:32 +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2024 at 03:40:56PM +0100, Ben Gainey wrote:
> > This change allows events to use PERF_SAMPLE READ with inherit
> > so long as PERF_SAMPLE_TID is also set.
> >
> > In this configuration, an event will be inherited into any
> > child processes / threads, allowing convenient profiling of a
> > multiprocess or multithreaded application, whilst allowing
> > profiling tools to collect per-thread samples, in particular
> > of groups of counters.
>
> Perhaps a few words on *WHY* this is important.
>
> > The read_format field of both PERF_RECORD_READ and
> > PERF_RECORD_SAMPLE
> > are changed by this new configuration, but calls to `read()` on the
> > same
> > event file descriptor are unaffected and continue to return the
> > cumulative total.
>
> This is unfortunate. Up to this point they were the same. Also, I see
> no
> change to the uapi file. So were you trying to say that only
> read_format::value is changed to be the thread local value as opposed
> to
> the hierarchy total?
>
> Please fix the wording to be unambiguous as to what is actually
> meant.
> Also try and justify why it is okay to break this symmetry.
Yes, the meaning of the PERF_RECORD_SAMPLE's read_format value changes
in this specific scenario to be a thread-local value rather than the
total.
I'll update and add some justification.
>
> > @@ -3532,11 +3544,18 @@ perf_event_context_sched_out(struct
> > task_struct *task, struct task_struct *next)
> > perf_ctx_disable(ctx, false);
> >
> > /* PMIs are disabled; ctx->nr_pending is stable. */
> > - if (local_read(&ctx->nr_pending) ||
> > + if (ctx->nr_inherit_read ||
> > + next_ctx->nr_inherit_read ||
> > + local_read(&ctx->nr_pending) ||
> > local_read(&next_ctx->nr_pending)) {
>
> This seems unfortunate, nr_pending and nr_inherit_read are both used
> exclusively to inhibit this context switch optimization. Surely they
> can
> share the exact same counter.
>
> That is, rename nr_pending and use it for both?
Sure, how about "nr_no_switch_fast" ?
>
> > /*
> > * Must not swap out ctx when there's pending
> > * events that rely on the ctx->task relation.
> > + *
> > + * Likewise, when a context contains inherit +
> > + * SAMPLE_READ events they should be switched
> > + * out using the slow path so that they are
> > + * treated as if they were distinct contexts.
> > */
> > raw_spin_unlock(&next_ctx->lock);
> > rcu_read_unlock();
> > @@ -4552,11 +4571,19 @@ static void __perf_event_read(void *info)
> > raw_spin_unlock(&ctx->lock);
> > }
> >
> > -static inline u64 perf_event_count(struct perf_event *event)
> > +static inline u64 perf_event_count_cumulative(struct perf_event
> > *event)
>
> I don't think you need this -- overly long and hard to type function
> name...
Sure, presumably you are happy with just calling
"perf_event_count(event, false)" everywhere it is currently used,
rather than renaming it to something shorter and keeping the two
functions?
>
> > {
> > return local64_read(&event->count) + atomic64_read(&event-
> > >child_count);
> > }
> >
> > +static inline u64 perf_event_count(struct perf_event *event, bool
> > self_value_only)
> > +{
> > + if (self_value_only && has_inherit_and_sample_read(&event->attr))
> > + return local64_read(&event->count);
>
> ... if this @self_value_only argument was actually used as such -- it
> isn't, see how you use 'from_sample' which is something else
> entirely.
> Which then also caused to you fix it up and make a mess with that &&
> has_inherit_and_sample_read() nonsense. (also, shorter function
> names,
> more good)
>
> > +
> > + return perf_event_count_cumulative(event);
> > +}
>
> That is, I would really rather you had:
>
> static inline u64 perf_event_count(struct perf_event *event, bool
> self)
> {
> if (self)
> return local64_read(&event->count);
>
> return local64_read(&event->count) + local64_read(&event-
> >child_count);
> }
>
> And then actually use that argument as intended.
Fair point.
I was trying to avoid the 3 subsequent uses all having to repeat
"from_sample && has_inherit_and_sample_read(&event->attr)", which feels
a bit of a pit-trappy.
I suppose I could pull that into a "use_self_value(from_sample,event)"?
>
> > @@ -7205,13 +7232,14 @@ void perf_event__output_id_sample(struct
> > perf_event *event,
> >
> > static void perf_output_read_one(struct perf_output_handle
> > *handle,
> > struct perf_event *event,
> > - u64 enabled, u64 running)
> > + u64 enabled, u64 running,
> > + bool from_sample)
> > {
> > u64 read_format = event->attr.read_format;
> > u64 values[5];
> > int n = 0;
> >
> > - values[n++] = perf_event_count(event);
> > + values[n++] = perf_event_count(event, from_sample);
>
> ...observe the fail... from_sample != self-value-only
By fail you are referring to the difference in names?
>
> > if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED) {
> > values[n++] = enabled +
> > atomic64_read(&event->child_total_time_enabled);
>
Thanks
Ben
next prev parent reply other threads:[~2024-06-07 10:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 14:40 [PATCH v7 0/4] perf: Support PERF_SAMPLE_READ with inherit Ben Gainey
2024-06-06 14:40 ` [PATCH v7 1/4] " Ben Gainey
2024-06-07 9:32 ` Peter Zijlstra
2024-06-07 10:16 ` Ben Gainey [this message]
2024-06-07 11:02 ` Peter Zijlstra
2024-06-07 14:04 ` Ben Gainey
2024-06-10 19:01 ` Peter Zijlstra
2024-06-06 14:40 ` [PATCH v7 2/4] tools/perf: Track where perf_sample_ids need per-thread periods Ben Gainey
2024-06-06 14:40 ` [PATCH v7 3/4] tools/perf: Correctly calculate sample period for inherited SAMPLE_READ values Ben Gainey
2024-06-06 14:40 ` [PATCH v7 4/4] tools/perf: Allow inherit + PERF_SAMPLE_READ when opening events Ben Gainey
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=451afb8eb03f1519c482a84a6c1cbd1e62222988.camel@arm.com \
--to=ben.gainey@arm.com \
--cc=James.Clark@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).