linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).