Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230715032915.97146-1-yangjihong1@huawei.com>
 <20230715032915.97146-3-yangjihong1@huawei.com> <CAP-5=fVysKhUn1YsUr0NBU2kVBDgkoczO861XwK5VCtkeYSRJA@mail.gmail.com>
 <993bd68c-c0ec-4960-d3b0-bd2dbda82402@huawei.com>
In-Reply-To: <993bd68c-c0ec-4960-d3b0-bd2dbda82402@huawei.com>
From:   Ian Rogers <irogers@google.com>
Date:   Fri, 28 Jul 2023 09:40:25 -0700
Message-ID: <CAP-5=fXmpaKrVLifHh5H7Lf_nhNLGWFS0=CLRT2yHK5guReNGA@mail.gmail.com>
Subject: Re: [PATCH v2 2/7] perf evlist: Add evlist__findnew_tracking_event() helper
To:     Yang Jihong <yangjihong1@huawei.com>
Cc:     peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
        mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
        jolsa@kernel.org, namhyung@kernel.org, adrian.hunter@intel.com,
        kan.liang@linux.intel.com, james.clark@arm.com,
        tmricht@linux.ibm.com, ak@linux.intel.com,
        anshuman.khandual@arm.com, linux-kernel@vger.kernel.org,
        linux-perf-users@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Jul 20, 2023 at 12:24=E2=80=AFAM Yang Jihong <yangjihong1@huawei.co=
m> wrote:
>
> Hello,
>
> On 2023/7/20 0:44, Ian Rogers wrote:
> > On Fri, Jul 14, 2023 at 8:31=E2=80=AFPM Yang Jihong <yangjihong1@huawei=
.com> wrote:
> >>
> >> Currently, intel-bts, intel-pt, and arm-spe may add a dummy event for
> >> tracking to the evlist. We may need to search for the dummy event for
> >> some settings. Therefore, add evlist__findnew_tracking_event() helper.
> >>
> >> evlist__findnew_tracking_event() also deal with system_wide maps if
> >> system_wide is true.
> >
> > I'm wondering if we can simplify the naming in the API, we have "dummy
> > event" which makes sense as we literally call the event "dummy",
> > "sideband" which refers to the kind of samples/events the dummy event
> > will record but "tracking" I think tends to get used as a verb rather
> > than a noun. So I think evlist__findnew_tracking_event should be
> > evlist__findnew_dummy_event.
> >
> Uh, from the discussion that followed, it seems that there is no
> consensus yet...
> If there is a clear consensus on whether to use "dummy event" or
> "tracking event", I will change the name of the API.
>
> I think sideband event is equivalent to tracking event (refer
> evsel__config(), tracking events include task, mmap, mmap2, and comm
> sideband events, which are all sideband).
>
> tracking event are instances of dummy event. For example, we create
> another dummy event to record the text poke event of ksymbol (refer perf
> record --kcore).
>
> An evlist contains only one tracking event, but can contain multiple
> dummy events.

Thanks for the feedback. So the tracking event is by definition the
first dummy event in the evlist? What is the purpose of the other
dummy events in this case? Perhaps we can get to an intention
revealing implementation something like:

/** The "tracking event" gathering sideband data is the first dummy
event in the list. */
struct evsel *evlist__findnew_tracking_event(struct evlist *evlist)
{
   struct evsel *dummy =3D evlist__find_first_dummy_event(evlist);

   if (!dummy) {
      dummy =3D evlist__add_dummy(evlist);
   }
   return dummy;
}

But I think the key thing for me is I'm still not sure what is going
on when there are multiple dummy events for you, what are the other
dummy events for other than tracking sideband data?

Thanks,
Ian

>
> Thanks,
> Yang