Re: [RFC PATCH v10 0/8] TPEBS counting mode support

[Namhyung Kim]

On Fri, May 31, 2024 at 12:00 AM Wang, Weilin <weilin.wang@xxxxxxxxx> wrote:
>
>
>
> > -----Original Message-----
> > From: Namhyung Kim <namhyung@xxxxxxxxxx>
> > Sent: Thursday, May 30, 2024 11:37 PM
> > To: Wang, Weilin <weilin.wang@xxxxxxxxx>
> > Cc: Ian Rogers <irogers@xxxxxxxxxx>; Arnaldo Carvalho de Melo
> > <acme@xxxxxxxxxx>; Peter Zijlstra <peterz@xxxxxxxxxxxxx>; Ingo Molnar
> > <mingo@xxxxxxxxxx>; Alexander Shishkin
> > <alexander.shishkin@xxxxxxxxxxxxxxx>; Jiri Olsa <jolsa@xxxxxxxxxx>; Hunter,
> > Adrian <adrian.hunter@xxxxxxxxx>; Kan Liang <kan.liang@xxxxxxxxxxxxxxx>;
> > linux-perf-users@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Taylor, Perry
> > <perry.taylor@xxxxxxxxx>; Alt, Samantha <samantha.alt@xxxxxxxxx>; Biggers,
> > Caleb <caleb.biggers@xxxxxxxxx>
> > Subject: Re: [RFC PATCH v10 0/8] TPEBS counting mode support
> >
> > Hello,
> >
> > On Tue, May 28, 2024 at 11:43 PM <weilin.wang@xxxxxxxxx> wrote:
> > >
> > > From: Weilin Wang <weilin.wang@xxxxxxxxx>
> > >
> > > 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 segfault is
> caused by store_evsel_id(). I could add another early return from store_evsel_id()
> if the evsel->retire_lat is true.

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

>
> After this change, it will eventually run and give me <not counted> results
> 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 value):
>
>         xxxxxxx event1
>         xxxxxxx event2
>         xxxxxxx event3
>         xx event1:R
>
> In the first case, the event1, event2 and event1:R are scheduled in the same
> group. On the other hand, in the second case, event1, event2 and event3 are
> 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 happens 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