All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: irogers@google.com, namhyung@kernel.org, mark.rutland@arm.com,
	maz@kernel.org, marcan@marcan.st, linux-kernel@vger.kernel.org,
	linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf top: Use evsel's cpus to replace user_requested_cpus
Date: Tue, 12 Dec 2023 13:58:24 -0300	[thread overview]
Message-ID: <ZXiRMDJpz3l27u7g@kernel.org> (raw)
In-Reply-To: <07677ab2-c29b-499b-b473-f7535fb27a8c@linux.intel.com>

Em Tue, Dec 12, 2023 at 10:56:15AM -0500, Liang, Kan escreveu:
> 
> 
> On 2023-12-11 4:13 p.m., Arnaldo Carvalho de Melo wrote:
> > Em Fri, Dec 08, 2023 at 01:08:55PM -0800, kan.liang@linux.intel.com escreveu:
> >> From: Kan Liang <kan.liang@linux.intel.com>
> >>
> >> perf top errors out on a hybrid machine
> >>  $perf top
> >>
> >>  Error:
> >>  The cycles:P event is not supported.
> >>
> >> The user_requested_cpus may contain CPUs that are invalid for a hybrid
> >> PMU. It causes perf_event_open to fail.

> > ?

> > All perf top expects is that the "cycles", the most basic one, be
> > collected, on all CPUs in the system.
 
> Yes, but for hybrid there is no single "cycles" event which can cover
> all CPUs. Perf has to split it into two cycles events, cpu_core/cycles/
> and cpu_atom/cycles/. Each event has its own CPU mask. If a event is
> opened on the unsupported CPU. The open fails. That's the reason perf
> top fails. So perf should only open the cycles event on the
> corresponding CPU.

Great explanation, please make sure it is present in the fix, i.e. in
the v2 you mentioned.
 
> >> The commit ef91871c960e ("perf evlist: Propagate user CPU maps
> >> intersecting core PMU maps") already intersect the requested CPU map
> >> with the CPU map of the PMU. Use the evsel's cpus to replace
> >> user_requested_cpus.
> >  
> >> The evlist's threads is also propagated to evsel's threads in
> >> __perf_evlist__propagate_maps(). Replace it as well.
> > 
> > Thanks, but please try to add more detail to the fix so as to help
> > others to consider looking at the patch.
> 
> OK. For the threads, the same as other tools, e.g., perf record, perf
> appends a dummy for the system wide event. For a per-thread event, the
> evlist's thread_map is assigned to the evsel. So using the evsel's
> threads is appropriate and also be consistent with other tools.
> 
> I will update the description and send a V2.
> 
> Thanks,
> Kan
> 
> > 
> > - Arnaldo
> >  
> >> Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
> >> Closes: https://lore.kernel.org/linux-perf-users/ZXNnDrGKXbEELMXV@kernel.org/
> >> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> >> ---
> >>  tools/perf/builtin-top.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> >> index ea8c7eca5eee..cce9350177e2 100644
> >> --- a/tools/perf/builtin-top.c
> >> +++ b/tools/perf/builtin-top.c
> >> @@ -1027,8 +1027,8 @@ static int perf_top__start_counters(struct perf_top *top)
> >>  
> >>  	evlist__for_each_entry(evlist, counter) {
> >>  try_again:
> >> -		if (evsel__open(counter, top->evlist->core.user_requested_cpus,
> >> -				     top->evlist->core.threads) < 0) {
> >> +		if (evsel__open(counter, counter->core.cpus,
> >> +				counter->core.threads) < 0) {
> >>  
> >>  			/*
> >>  			 * Specially handle overwrite fall back.

  reply	other threads:[~2023-12-12 16:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 21:08 [PATCH] perf top: Use evsel's cpus to replace user_requested_cpus kan.liang
2023-12-11 21:13 ` Arnaldo Carvalho de Melo
2023-12-12 15:56   ` Liang, Kan
2023-12-12 16:58     ` Arnaldo Carvalho de Melo [this message]
2023-12-12 17:23     ` Namhyung Kim
2023-12-12 18:00       ` Ian Rogers
2023-12-12 18:31         ` Mark Rutland
2023-12-12 18:49           ` Namhyung Kim
2023-12-12 19:22             ` Liang, Kan
2023-12-13 12:05               ` Mark Rutland
2023-12-12 19:26             ` Ian Rogers
2023-12-15 15:36           ` Arnaldo Carvalho de Melo
2023-12-15 16:51             ` Mark Rutland
2023-12-15 17:49               ` Arnaldo Carvalho de Melo
2024-01-05 12:31                 ` Mark Rutland
2023-12-15 17:59             ` Liang, Kan
2023-12-15 18:26               ` Arnaldo Carvalho de Melo
2023-12-15 18:53                 ` Liang, Kan
2023-12-18 20:23                   ` Arnaldo Carvalho de Melo
2023-12-18 21:07                     ` Liang, Kan
2023-12-12  0:02 ` Ian Rogers

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=ZXiRMDJpz3l27u7g@kernel.org \
    --to=acme@kernel.org \
    --cc=irogers@google.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=namhyung@kernel.org \
    /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.