All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: "Wang, Weilin" <weilin.wang@intel.com>
Cc: Ian Rogers <irogers@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	"Hunter, Adrian" <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	"linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Taylor, Perry" <perry.taylor@intel.com>,
	"Alt, Samantha" <samantha.alt@intel.com>,
	"Biggers, Caleb" <caleb.biggers@intel.com>
Subject: Re: [RFC PATCH v11 3/8] perf stat: Fork and launch perf record when perf stat needs to get retire latency value for a metric.
Date: Mon, 10 Jun 2024 16:58:55 -0700	[thread overview]
Message-ID: <ZmeTP8cnK12dgJxq@google.com> (raw)
In-Reply-To: <CO6PR11MB5635B74E5C5FFE7182501DCBEEC52@CO6PR11MB5635.namprd11.prod.outlook.com>

On Sun, Jun 09, 2024 at 03:02:21AM +0000, Wang, Weilin wrote:
> 
> 
> > -----Original Message-----
> > From: Namhyung Kim <namhyung@kernel.org>
> > Sent: Saturday, June 8, 2024 7:28 PM
> > To: Wang, Weilin <weilin.wang@intel.com>
> > Cc: Ian Rogers <irogers@google.com>; Arnaldo Carvalho de Melo
> > <acme@kernel.org>; Peter Zijlstra <peterz@infradead.org>; Ingo Molnar
> > <mingo@redhat.com>; Alexander Shishkin
> > <alexander.shishkin@linux.intel.com>; Jiri Olsa <jolsa@kernel.org>; Hunter,
> > Adrian <adrian.hunter@intel.com>; Kan Liang <kan.liang@linux.intel.com>;
> > linux-perf-users@vger.kernel.org; linux-kernel@vger.kernel.org; Taylor, Perry
> > <perry.taylor@intel.com>; Alt, Samantha <samantha.alt@intel.com>; Biggers,
> > Caleb <caleb.biggers@intel.com>
> > Subject: Re: [RFC PATCH v11 3/8] perf stat: Fork and launch perf record when
> > perf stat needs to get retire latency value for a metric.
> > 
> > On Fri, Jun 07, 2024 at 08:45:13PM +0000, Wang, Weilin wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Namhyung Kim <namhyung@kernel.org>
> > > > Sent: Friday, June 7, 2024 12:20 PM
> > > > To: Wang, Weilin <weilin.wang@intel.com>
> > > > Cc: Ian Rogers <irogers@google.com>; Arnaldo Carvalho de Melo
> > > > <acme@kernel.org>; Peter Zijlstra <peterz@infradead.org>; Ingo Molnar
> > > > <mingo@redhat.com>; Alexander Shishkin
> > > > <alexander.shishkin@linux.intel.com>; Jiri Olsa <jolsa@kernel.org>; Hunter,
> > > > Adrian <adrian.hunter@intel.com>; Kan Liang <kan.liang@linux.intel.com>;
> > > > linux-perf-users@vger.kernel.org; linux-kernel@vger.kernel.org; Taylor,
> > Perry
> > > > <perry.taylor@intel.com>; Alt, Samantha <samantha.alt@intel.com>;
> > Biggers,
> > > > Caleb <caleb.biggers@intel.com>
> > > > Subject: Re: [RFC PATCH v11 3/8] perf stat: Fork and launch perf record
> > when
> > > > perf stat needs to get retire latency value for a metric.
> > > >
> > > > On Fri, Jun 07, 2024 at 01:07:12AM +0000, Wang, Weilin wrote:
> > [SNIP]
> > > > > > > @@ -2186,6 +2240,9 @@ static int evsel__open_cpu(struct evsel
> > *evsel,
> > > > > > struct perf_cpu_map *cpus,
> > > > > > >  		return 0;
> > > > > > >  	}
> > > > > > >
> > > > > > > +	if (evsel__is_retire_lat(evsel))
> > > > > > > +		return tpebs_start(evsel->evlist, cpus);
> > > > > >
> > > > > > As it works with evlist, I think it's better to put this code there.
> > > > > > But it seems perf stat doesn't call the evlist API for open, then we
> > > > > > can add this to somewhere in __run_perf_stat() directly.
> > > > > >
> > > > > > > +
> > > > > > >  	err = __evsel__prepare_open(evsel, cpus, threads);
> > > > > > >  	if (err)
> > > > > > >  		return err;
> > > > > > > @@ -2376,6 +2433,8 @@ int evsel__open(struct evsel *evsel, struct
> > > > > > perf_cpu_map *cpus,
> > > > > > >
> > > > > > >  void evsel__close(struct evsel *evsel)
> > > > > > >  {
> > > > > > > +	if (evsel__is_retire_lat(evsel))
> > > > > > > +		tpebs_delete();
> > > > > >
> > > > > > Ditto.
> > > > >
> > > > > Hi Namhyung,
> > > > >
> > > > > I hope both this and the one above on open could stay in evsel level
> > because
> > > > > these are operations on retire_latency evsel.
> > > >
> > > > Then I think you need to remove the specific evsel not the all tpebs
> > > > events.
> > > >
> > > > > At the same time, a lot of the
> > > > > previous several versions of work was to move TPEBS code out from perf
> > > > stat to
> > > > > evsel to make it more generic. I think move these back to
> > __run_perf_stat()
> > > > are
> > > > > opposite to that goal.
> > > >
> > > > Oh, I meant you can have the logic in utils/intel-tpebs.c but add a call
> > > > to tpebs_delete() in __run_perf_stat().  I think it'd better to keep it
> > > > in evlist__close() but we don't use evlist__open() for perf stat so it's
> > > > not symmetric. :(
> > > >
> > > > Anyway, all I want to say is that tpebs APIs work on evlist level.  So I
> > > > think it's natural that they are called for the whole list, not for an
> > > > event/evsel.
> > >
> > > I think we're trying to work at evsel level and open(remove) or close one
> > > retire_latency evsel at a time. In addition to that, we put all the required
> > retire_latency
> > > together in one perf record launch in order to reduce overhead to fork
> > multiple perf
> > > record. I hope this makes sense.
> > 
> > Well.. I think we can do something like this in the current code.
> > 
> > __run_perf_stat():
> >   ...
> > 
> >   tpebs__start(evlist, target);
> > 
> >   evlist__for_each_cpu(...) {
> >       if (create_perf_steat_counter() < 0) {
> >           ....
> > 
> > instead of doing it in the evsel__open().  What's the issue with this
> > approach?
> 
> This is basically how tpebs__start() was invoked in v9 (https://lore.kernel.org/all/CAM9d7ci7tgjR8LVNx+ZrFKMGo+OZn=eFSksPL56MeP_Q84PkMw@mail.gmail.com/)
> 
> I changed it in v10 so that it works at evsel level. 
> 
> Ian, could you please let me know what do you think about this? 

Ok, we sync-ed offline and agreed to have it in evsel level.  I still
think it's better to handle it in evlist level (at least for TPEBS) but
unfortunately we don't use evlist__open() consistently and there are
places it's not called.  Probably we need to convert the all call sites
to open evsel to be from evlist__open() then move tpebs__start() there.

Thanks,
Namhyung


  reply	other threads:[~2024-06-10 23:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-05  5:21 [RFC PATCH v11 0/8]TPEBS counting mode support weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 1/8] perf parse-events: Add a retirement latency modifier weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 2/8] perf data: Allow to use given fd in data->file.fd weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 3/8] perf stat: Fork and launch perf record when perf stat needs to get retire latency value for a metric weilin.wang
2024-06-06 23:20   ` Namhyung Kim
2024-06-07  1:07     ` Wang, Weilin
2024-06-07 19:20       ` Namhyung Kim
2024-06-07 20:45         ` Wang, Weilin
2024-06-09  2:27           ` Namhyung Kim
2024-06-09  3:02             ` Wang, Weilin
2024-06-10 23:58               ` Namhyung Kim [this message]
2024-06-05  5:21 ` [RFC PATCH v11 4/8] perf stat: Plugin retire_lat value from sampled data to evsel weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 5/8] perf vendor events intel: Add MTL metric json files weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 6/8] perf stat: Add command line option for enabling tpebs recording weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 7/8] perf Document: Add TPEBS to Documents weilin.wang
2024-06-05  5:21 ` [RFC PATCH v11 8/8] perf test: Add test for Intel TPEBS counting mode weilin.wang

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=ZmeTP8cnK12dgJxq@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=caleb.biggers@intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=perry.taylor@intel.com \
    --cc=peterz@infradead.org \
    --cc=samantha.alt@intel.com \
    --cc=weilin.wang@intel.com \
    /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.