mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Robin Murphy <robin.murphy@arm.com>, Leo Yan <leo.yan@arm.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] perf list: Don't deduplicate core PMUs when listing events
Date: Fri, 7 Mar 2025 14:08:21 +0000	[thread overview]
Message-ID: <9a3cd3ea-6352-455a-b883-f8f3488002bd@linaro.org> (raw)
In-Reply-To: <CAP-5=fVHE41=RuBf2fS6anTmNOy3DXZbUSw6p+SBaCM9oD-YOA@mail.gmail.com>



On 05/03/2025 9:51 pm, Ian Rogers wrote:
> On Tue, Mar 4, 2025 at 5:50 AM James Clark <james.clark@linaro.org> wrote:
>>
>> Commit 7afbf90ea2e2 ("perf pmu: Don't de-duplicate core PMUs") fixed a
>> display mismatch related to deduplication within a single PMU, but it
>> didn't fix the case where deduplicated PMUs aren't listed at all.
>>
>> Fix it by using the same function which takes is_core into account,
>> except in the use_core_pmus block where it's always going to be true.
>> Before this change, -v would be required to get the same behavior for
>> core PMUs. Now it's no longer required:
>>
>> Before:
>>   $ perf list | grep br_indirect_spec -A 1
>>   br_indirect_spec
>>      [Branch speculatively executed,indirect branch. Unit: armv8_cortex_a53]
>>
>> After:
>>   $ perf list | grep br_indirect_spec -A 2
>>      [Branch speculatively executed,indirect branch. Unit: armv8_cortex_a53,
>>       armv8_cortex_a57]
>>
>> Signed-off-by: James Clark <james.clark@linaro.org>
>> ---
>>   tools/perf/util/pmu.c  | 5 +++--
>>   tools/perf/util/pmu.h  | 2 ++
>>   tools/perf/util/pmus.c | 8 +++++---
>>   3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
>> index 57450c73fb63..caff0d309012 100644
>> --- a/tools/perf/util/pmu.c
>> +++ b/tools/perf/util/pmu.c
>> @@ -834,9 +834,10 @@ static int is_sysfs_pmu_core(const char *name)
>>    *
>>    * @skip_duplicate_pmus: False in verbose mode so all uncore PMUs are visible
>>    */
>> -static size_t pmu_deduped_name_len(const struct perf_pmu *pmu, const char *name,
>> -                                  bool skip_duplicate_pmus)
>> +size_t pmu_deduped_name_len(const struct perf_pmu *pmu, const char *name,
>> +                           bool skip_duplicate_pmus)
> 
> nit: I think the name should be perf_pmu__deduped_name_len for
> consistency with the other non-static functions.
> 

Will change.

>>   {
>> +       name = name ?: "";
> 
> nit: Should this just use pmu->name ?
> 

I can keep this part at the callsite in 
perf_pmus__scan_skip_duplicates() to avoid any confusion about this 
function accessing pmu->name or not. The only reason this function takes 
a separate name parameter is to allow it to work with struct 
pmu_event_info elsewhere as well.

>>          return skip_duplicate_pmus && !pmu->is_core
>>                  ? pmu_name_len_no_suffix(name)
>>                  : strlen(name);
>> diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
>> index b93014cc3670..ce6a394a695d 100644
>> --- a/tools/perf/util/pmu.h
>> +++ b/tools/perf/util/pmu.h
>> @@ -297,5 +297,7 @@ struct perf_pmu *perf_pmus__find_core_pmu(void);
>>
>>   const char *perf_pmu__name_from_config(struct perf_pmu *pmu, u64 config);
>>   bool perf_pmu__is_fake(const struct perf_pmu *pmu);
>> +size_t pmu_deduped_name_len(const struct perf_pmu *pmu, const char *name,
>> +                           bool skip_duplicate_pmus);
>>
>>   #endif /* __PMU_H */
>> diff --git a/tools/perf/util/pmus.c b/tools/perf/util/pmus.c
>> index cb1b14ade25b..1acc27af4d02 100644
>> --- a/tools/perf/util/pmus.c
>> +++ b/tools/perf/util/pmus.c
>> @@ -358,12 +358,14 @@ static struct perf_pmu *perf_pmus__scan_skip_duplicates(struct perf_pmu *pmu)
>>          if (!pmu) {
>>                  pmu_read_sysfs(PERF_TOOL_PMU_TYPE_ALL_MASK);
>>                  pmu = list_prepare_entry(pmu, &core_pmus, list);
>> -       } else
>> -               last_pmu_name_len = pmu_name_len_no_suffix(pmu->name ?: "");
>> +       } else {
>> +               last_pmu_name_len = pmu_deduped_name_len(pmu, pmu->name,
>> +                                                        /*skip_duplicate_pmus=*/true);
>> +       }
>>
>>          if (use_core_pmus) {
>>                  list_for_each_entry_continue(pmu, &core_pmus, list) {
>> -                       int pmu_name_len = pmu_name_len_no_suffix(pmu->name ?: "");
>> +                       int pmu_name_len = strlen(pmu->name ?: "");
>>
>>                          if (last_pmu_name_len == pmu_name_len &&
>>                              !strncmp(last_pmu_name, pmu->name ?: "", pmu_name_len))
> 
> Can this code be removed given there shouldn't be core PMUs with
> identical names? ie:
> ```
> if (use_core_pmus) {
>      list_for_each_entry_continue(pmu, &core_pmus, list)
>          return pmu;
> 
>      pmu = NULL;
>      pmu = list_prepare_entry(pmu, &other_pmus, list);
> }
> ```
> 
> Thanks,
> Ian
> 

Even better, yes it probably can.

Thanks
James

>>
>> --
>> 2.34.1
>>


  reply	other threads:[~2025-03-07 14:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04 13:49 [PATCH 0/3] perf list: Collapse similar events across PMUs James Clark
2025-03-04 13:49 ` [PATCH 1/3] perf list: Order events by event name before PMU name James Clark
2025-03-05 20:59   ` Ian Rogers
2025-03-04 13:49 ` [PATCH 2/3] perf list: Collapse similar events across PMUs James Clark
2025-03-05  9:35   ` Leo Yan
2025-03-05  9:49     ` Leo Yan
2025-03-05 21:40   ` Ian Rogers
2025-03-07 14:08     ` James Clark
2025-03-07 17:35       ` Ian Rogers
2025-03-10 10:04         ` James Clark
2025-03-11 14:13         ` James Clark
2025-03-11 15:14           ` Ian Rogers
2025-03-11 16:41             ` James Clark
2025-03-04 13:49 ` [PATCH 3/3] perf list: Don't deduplicate core PMUs when listing events James Clark
2025-03-05 21:51   ` Ian Rogers
2025-03-07 14:08     ` James Clark [this message]
2025-03-05  9:26 ` [PATCH 0/3] perf list: Collapse similar events across PMUs Leo Yan
2025-03-05 20:38 ` Ian Rogers
2025-03-07 14:47   ` James Clark

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=9a3cd3ea-6352-455a-b883-f8f3488002bd@linaro.org \
    --to=james.clark@linaro.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®