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;
Subject: Re: [PATCH v2 2/7] perf evlist: Add evlist__findnew_tracking_event()
 helper
To:     Ian Rogers <irogers@google.com>,
        Adrian Hunter <adrian.hunter@intel.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>,
        <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>
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>
 <CAP-5=fXmpaKrVLifHh5H7Lf_nhNLGWFS0=CLRT2yHK5guReNGA@mail.gmail.com>
From:   Yang Jihong <yangjihong1@huawei.com>
Message-ID: <ff345f02-cebd-9e76-b15c-e07249f516f1@huawei.com>
Date:   Sat, 29 Jul 2023 10:10:59 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAP-5=fXmpaKrVLifHh5H7Lf_nhNLGWFS0=CLRT2yHK5guReNGA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hello,

On 2023/7/29 0:40, Ian Rogers wrote:
> On Thu, Jul 20, 2023 at 12:24 AM Yang Jihong <yangjihong1@huawei.com> wrote:
>>
>> Hello,
>>
>> On 2023/7/20 0:44, Ian Rogers wrote:
>>> On Fri, Jul 14, 2023 at 8:31 PM 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
Uh... It may not be the first dummy event, but evsel->track must be 
true. Only one evsel in an evlist meets this condition.

> 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 = evlist__find_first_dummy_event(evlist);
> 
>     if (!dummy) {
>        dummy = 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?
> 
For other dummy events, perf record will open a dummy event to track 
ksymbol text_poke when "--kcore" option is used.
I thinks tracking ksymbol text_poke separately it needs to be processed 
independently, go system_wide and enable immediately.

All of the above is my understanding, may need Adrian to confirm whether 
it is accurate.

Thanks,
Yang