All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Rogers <irogers@google.com>
To: zhengjun.xing@linux.intel.com
Cc: acme@kernel.org, peterz@infradead.org, mingo@redhat.com,
	alexander.shishkin@intel.com, jolsa@kernel.org,
	namhyung@kernel.org, linux-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org, ak@linux.intel.com,
	kan.liang@linux.intel.com
Subject: Re: [PATCH 1/2] perf print-events: Fix "perf list" can not display the PMU prefix for some hybrid cache events
Date: Wed, 21 Sep 2022 20:12:38 -0700	[thread overview]
Message-ID: <CAP-5=fUecPUJ-Z5WwbjVgA6b6r3-MmmfpjE+iw_pAK_K+rhxMA@mail.gmail.com> (raw)
In-Reply-To: <20220922014904.3665674-1-zhengjun.xing@linux.intel.com>

On Wed, Sep 21, 2022 at 6:47 PM <zhengjun.xing@linux.intel.com> wrote:
>
> From: Zhengjun Xing <zhengjun.xing@linux.intel.com>
>
> Some hybrid hardware cache events are only available on one CPU PMU. For
> example, 'L1-dcache-load-misses' is only available on cpu_core. We have
> supported in the perf list clearly reporting this info, the function works
> fine before but recently the argument "config" in API is_event_supported()
> is changed from "u64" to "unsigned int" which caused a regression, the
> "perf list" then can not display the PMU prefix for some hybrid cache
> events. For the hybrid systems, the PMU type ID is stored at config[63:32],
> define config to "unsigned int" will miss the PMU type ID information, then
> the regression happened, the config should be defined as "u64".
>
> Before:
>  # ./perf list |grep "Hardware cache event"
>   L1-dcache-load-misses                              [Hardware cache event]
>   L1-dcache-loads                                    [Hardware cache event]
>   L1-dcache-stores                                   [Hardware cache event]
>   L1-icache-load-misses                              [Hardware cache event]
>   L1-icache-loads                                    [Hardware cache event]
>   LLC-load-misses                                    [Hardware cache event]
>   LLC-loads                                          [Hardware cache event]
>   LLC-store-misses                                   [Hardware cache event]
>   LLC-stores                                         [Hardware cache event]
>   branch-load-misses                                 [Hardware cache event]
>   branch-loads                                       [Hardware cache event]
>   dTLB-load-misses                                   [Hardware cache event]
>   dTLB-loads                                         [Hardware cache event]
>   dTLB-store-misses                                  [Hardware cache event]
>   dTLB-stores                                        [Hardware cache event]
>   iTLB-load-misses                                   [Hardware cache event]
>   node-load-misses                                   [Hardware cache event]
>   node-loads                                         [Hardware cache event]
>
> After:
>  # ./perf list |grep "Hardware cache event"
>   L1-dcache-loads                                    [Hardware cache event]
>   L1-dcache-stores                                   [Hardware cache event]
>   L1-icache-load-misses                              [Hardware cache event]
>   LLC-load-misses                                    [Hardware cache event]
>   LLC-loads                                          [Hardware cache event]
>   LLC-store-misses                                   [Hardware cache event]
>   LLC-stores                                         [Hardware cache event]
>   branch-load-misses                                 [Hardware cache event]
>   branch-loads                                       [Hardware cache event]
>   cpu_atom/L1-icache-loads/                          [Hardware cache event]
>   cpu_core/L1-dcache-load-misses/                    [Hardware cache event]
>   cpu_core/node-load-misses/                         [Hardware cache event]
>   cpu_core/node-loads/                               [Hardware cache event]
>   dTLB-load-misses                                   [Hardware cache event]
>   dTLB-loads                                         [Hardware cache event]
>   dTLB-store-misses                                  [Hardware cache event]
>   dTLB-stores                                        [Hardware cache event]
>   iTLB-load-misses                                   [Hardware cache event]
>
> Fixes: 9b7c7728f4e4 ("perf parse-events: Break out tracepoint and printing")
> Signed-off-by: Zhengjun Xing <zhengjun.xing@linux.intel.com>
> Reviewed-by: Kan Liang <kan.liang@linux.intel.com>

Acked-by: Ian Rogers <irogers@google.com>

Sorry for this breakage, I suspect that a long review on the
refactoring CL meant that I missed the intervening fix. Can we add a
test on this? It would need to be hybrid specific and skip otherwise.

Thanks,
Ian

> ---
>  tools/perf/util/print-events.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/print-events.c b/tools/perf/util/print-events.c
> index ba1ab5134685..04050d4f6db8 100644
> --- a/tools/perf/util/print-events.c
> +++ b/tools/perf/util/print-events.c
> @@ -239,7 +239,7 @@ void print_sdt_events(const char *subsys_glob, const char *event_glob,
>         strlist__delete(sdtlist);
>  }
>
> -static bool is_event_supported(u8 type, unsigned int config)
> +static bool is_event_supported(u8 type, u64 config)
>  {
>         bool ret = true;
>         int open_return;
> --
> 2.25.1
>

  parent reply	other threads:[~2022-09-22  3:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  1:49 [PATCH 1/2] perf print-events: Fix "perf list" can not display the PMU prefix for some hybrid cache events zhengjun.xing
2022-09-22  1:49 ` [PATCH 2/2] perf parse-events: Remove "not supported" " zhengjun.xing
2022-09-22  3:16   ` Ian Rogers
2022-09-22  8:04     ` Xing Zhengjun
2022-09-22  3:12 ` Ian Rogers [this message]
2022-09-22  6:44   ` [PATCH 1/2] perf print-events: Fix "perf list" can not display the PMU prefix for some " Xing Zhengjun

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='CAP-5=fUecPUJ-Z5WwbjVgA6b6r3-MmmfpjE+iw_pAK_K+rhxMA@mail.gmail.com' \
    --to=irogers@google.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@intel.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=zhengjun.xing@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.