Received-SPF: pass (google.com: domain of linux-kernel+bounces-197505-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240529064327.4080674-1-weilin.wang@intel.com>
 <CAM9d7cj676sty01zqJVyk9DVesVYNFgVTZ329X=UP3xgV2aDfA@mail.gmail.com> <CO6PR11MB5635D7581425EF0F089EA781EEFC2@CO6PR11MB5635.namprd11.prod.outlook.com>
In-Reply-To: <CO6PR11MB5635D7581425EF0F089EA781EEFC2@CO6PR11MB5635.namprd11.prod.outlook.com>
From: Namhyung Kim <namhyung@kernel.org>
Date: Fri, 31 May 2024 14:30:02 -0700
Message-ID: <CAM9d7chSC=n2sCc_nhgwqHYnBhSjMhH1quAY6_JWXNhrk1ri8Q@mail.gmail.com>
Subject: Re: [RFC PATCH v10 0/8] TPEBS counting mode support
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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 31, 2024 at 12:00=E2=80=AFAM Wang, Weilin <weilin.wang@intel.co=
m> wrote:
>
>
>
> > -----Original Message-----
> > From: Namhyung Kim <namhyung@kernel.org>
> > Sent: Thursday, May 30, 2024 11:37 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>; Hun=
ter,
> > 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>; Bigge=
rs,
> > Caleb <caleb.biggers@intel.com>
> > Subject: Re: [RFC PATCH v10 0/8] TPEBS counting mode support
> >
> > Hello,
> >
> > On Tue, May 28, 2024 at 11:43=E2=80=AFPM <weilin.wang@intel.com> wrote:
> > >
> > > From: Weilin Wang <weilin.wang@intel.com>
> > >
> > > I have tried not to count retire_latency events but did not succeed.
> > > In particular, I tried the following methods:
> > >  - Convert retire_latency event to dummy event in event parser.
> > >  - Early bail out in evsel__open_cpu() and store_evsel_ids().
> > >
> > > The first method fails and causes non-retire_latency events with the =
same
> > event
> > > name return 0 count.
> > >
> > > The second method fails and causes all the events in the same group
> > returning
> > > "<not counted>" results.
> >
> > Can you please describe where it fails?  Is it failing on other events
> > because the tpebs event is a leader of the group?  I think you wanted
> > to avoid having it in the leader position.  If we can skip any actual
> > operations (open/close/enable/disable/read) for the tpebs events, then
> > it could be fine..
>
> It does not fail with the code in this patch set. But if I make it return=
 directly
> from tpebs_start() in evsel__open_cpu(), it will cause segfault. The segf=
ault is
> caused by store_evsel_id(). I could add another early return from store_e=
vsel_id()
> if the evsel->retire_lat is true.

Yeah, I think event:R should not go to kernel from perf stat and you need t=
o
handle that in the tools.

>
> After this change, it will eventually run and give me <not counted> resul=
ts
> like below:
>
>         <not counted> event1
>         <not counted> event2
>         xx event1:R
>
> In a different case, it may seem to work (xxxxxx stands for some valid va=
lue):
>
>         xxxxxxx event1
>         xxxxxxx event2
>         xxxxxxx event3
>         xx event1:R
>
> In the first case, the event1, event2 and event1:R are scheduled in the s=
ame
> group. On the other hand, in the second case, event1, event2 and event3 a=
re
> in one group, while event1:R is in a different group.

If you don't open event1:R then the kernel only sees event1 and event2.

>
> Based on these two different type of results, I believe the failure happe=
ns in
> the group that include a :R event. I've added the change to arch_evlist__=
cmp()
> so that a :R event would not be a leader of the group.
>
> I think I've made evsel__open_cpu() return before it create fd and make
> store_evsel_id() not to read and store fd. I'm not sure where I'm missing=
. Please
> let me know if you have any suggestions.

As I said, please don't open event1:R (for perf stat) and let tpebs_stop() =
set
the value using the data from perf record in background.

Thanks,
Namhyung