All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: Ian Rogers <irogers@google.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Yang Jihong <yangjihong1@huawei.com>,
	Leo Yan <leo.yan@linaro.org>, Sandipan Das <sandipan.das@amd.com>,
	Ravi Bangoria <ravi.bangoria@amd.com>,
	linux-perf-users <linux-perf-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ajay Kaher <akaher@vmware.com>,
	Alexey Makhalov <amakhalov@vmware.com>
Subject: Re: [RFC PATCH v2] perf evsel: Fallback to task-clock when not system wide
Date: Tue, 5 Dec 2023 12:25:50 -0300	[thread overview]
Message-ID: <ZW9A/jpVNdeNZYnh@kernel.org> (raw)
In-Reply-To: <CFCEDA00-D3CB-450A-B9E5-AA5D7CEEA1CE@linux.vnet.ibm.com>

Em Tue, Dec 05, 2023 at 04:51:01PM +0530, Athira Rajeev escreveu:
> 
> 
> > On 21-Nov-2023, at 5:34 AM, Ian Rogers <irogers@google.com> wrote:
> > 
> > When the cycles event isn't available evsel will fallback to the
> > cpu-clock software event. task-clock is similar to cpu-clock but only
> > runs when the process is running. Falling back to cpu-clock when not
> > system wide leads to confusion, by falling back to task-clock it is
> > hoped the confusion is less.
> > 
> > Pass the target to determine if task-clock is more appropriate. Update
> > a nearby comment and debug string for the change.
> > 
> > ---
> > v2. Use target__has_cpu as suggested by Namhyung.
> > https://lpc.events/event/17/contributions/1556/
> > 
> > Signed-off-by: Ian Rogers <irogers@google.com>
> > ---
> > tools/perf/builtin-record.c |  2 +-
> > tools/perf/builtin-stat.c   |  2 +-
> > tools/perf/builtin-top.c    |  2 +-
> > tools/perf/util/evsel.c     | 18 ++++++++++--------
> > tools/perf/util/evsel.h     |  3 ++-
> > 5 files changed, 15 insertions(+), 12 deletions(-)
> > 
> > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> > index 8ec818568662..d8bb59511fdd 100644
> > --- a/tools/perf/builtin-record.c
> > +++ b/tools/perf/builtin-record.c
> > @@ -1350,7 +1350,7 @@ static int record__open(struct record *rec)
> > evlist__for_each_entry(evlist, pos) {
> > try_again:
> > if (evsel__open(pos, pos->core.cpus, pos->core.threads) < 0) {
> > - if (evsel__fallback(pos, errno, msg, sizeof(msg))) {
> > + if (evsel__fallback(pos, &opts->target, errno, msg, sizeof(msg))) {
> 
> Hi Ian
> 
> Tested this with perf record and I could find the code fallback to using task-clock
> 
> ./perf record -v ls
> Warning:
> The cycles event is not supported, trying to fall back to task-clock

Ok, so I'll take that as a Tested-by: you, ok?

The "perf stat" part can be addressed in a follow up patch, when that
error handling is researched to remember why we have that ->supported,
->errored thing.

- Arnaldo
 
> But in case of “perf stat”, in my environment, found that the code path won't invoke “evsel__fallback”.
> 
> Snippet for builtin-stat.c
>             if (errno == EINVAL || errno == ENOSYS ||
>             errno == ENOENT || errno == EOPNOTSUPP ||
>             errno == ENXIO) {
>                 if (verbose > 0)
>                         ui__warning("%s event is not supported by the kernel.\n",
>                                     evsel__name(counter));
>                 counter->supported = false;
>                 /*
>                  * errored is a sticky flag that means one of the counter's
>                  * cpu event had a problem and needs to be reexamined.
>                  */
>                 counter->errored = true;
> 
>                 if ((evsel__leader(counter) != counter) ||
>                     !(counter->core.leader->nr_members > 1))
>                         return COUNTER_SKIP;
>         } else if (evsel__fallback(counter, &target, errno, msg, sizeof(msg))) {
>                 if (verbose > 0)
>                         ui__warning("%s\n", msg);
>                 return COUNTER_RETRY;
> 
> So if the perf_event_open returns ENOENT, we won’t do a fallback in builtin-stat.c
> Should we address cycles differently here ? Any comments ?
> 
> Thanks
> Athira
> >   
> > if (verbose > 0)
> > ui__warning("%s\n", msg);
> > goto try_again;
> > diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> > index a3af805a1d57..d8e5d6f7a87a 100644
> > --- a/tools/perf/builtin-stat.c
> > +++ b/tools/perf/builtin-stat.c
> > @@ -653,7 +653,7 @@ static enum counter_recovery stat_handle_error(struct evsel *counter)
> > if ((evsel__leader(counter) != counter) ||
> >    !(counter->core.leader->nr_members > 1))
> > return COUNTER_SKIP;
> > - } else if (evsel__fallback(counter, errno, msg, sizeof(msg))) {
> > + } else if (evsel__fallback(counter, &target, errno, msg, sizeof(msg))) {
> > if (verbose > 0)
> > ui__warning("%s\n", msg);
> > return COUNTER_RETRY;
> > diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> > index ea8c7eca5eee..1e42bd1c7d5a 100644
> > --- a/tools/perf/builtin-top.c
> > +++ b/tools/perf/builtin-top.c
> > @@ -1044,7 +1044,7 @@ static int perf_top__start_counters(struct perf_top *top)
> >    perf_top_overwrite_fallback(top, counter))
> > goto try_again;
> > 
> > - if (evsel__fallback(counter, errno, msg, sizeof(msg))) {
> > + if (evsel__fallback(counter, &opts->target, errno, msg, sizeof(msg))) {
> > if (verbose > 0)
> > ui__warning("%s\n", msg);
> > goto try_again;
> > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > index a5da74e3a517..532f34d9fcb5 100644
> > --- a/tools/perf/util/evsel.c
> > +++ b/tools/perf/util/evsel.c
> > @@ -2853,7 +2853,8 @@ u64 evsel__intval_common(struct evsel *evsel, struct perf_sample *sample, const
> > 
> > #endif
> > 
> > -bool evsel__fallback(struct evsel *evsel, int err, char *msg, size_t msgsize)
> > +bool evsel__fallback(struct evsel *evsel, struct target *target, int err,
> > +     char *msg, size_t msgsize)
> > {
> > int paranoid;
> > 
> > @@ -2861,18 +2862,19 @@ bool evsel__fallback(struct evsel *evsel, int err, char *msg, size_t msgsize)
> >    evsel->core.attr.type   == PERF_TYPE_HARDWARE &&
> >    evsel->core.attr.config == PERF_COUNT_HW_CPU_CYCLES) {
> > /*
> > - * If it's cycles then fall back to hrtimer based
> > - * cpu-clock-tick sw counter, which is always available even if
> > - * no PMU support.
> > + * If it's cycles then fall back to hrtimer based cpu-clock sw
> > + * counter, which is always available even if no PMU support.
> > *
> > * PPC returns ENXIO until 2.6.37 (behavior changed with commit
> > * b0a873e).
> > */
> > - scnprintf(msg, msgsize, "%s",
> > -"The cycles event is not supported, trying to fall back to cpu-clock-ticks");
> > -
> > evsel->core.attr.type   = PERF_TYPE_SOFTWARE;
> > - evsel->core.attr.config = PERF_COUNT_SW_CPU_CLOCK;
> > + evsel->core.attr.config = target__has_cpu(target)
> > + ? PERF_COUNT_SW_CPU_CLOCK
> > + : PERF_COUNT_SW_TASK_CLOCK;
> > + scnprintf(msg, msgsize,
> > + "The cycles event is not supported, trying to fall back to %s",
> > + target__has_cpu(target) ? "cpu-clock" : "task-clock");
> > 
> > zfree(&evsel->name);
> > return true;
> > diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> > index f19ac9f027ef..efbb6e848287 100644
> > --- a/tools/perf/util/evsel.h
> > +++ b/tools/perf/util/evsel.h
> > @@ -460,7 +460,8 @@ static inline bool evsel__is_clock(const struct evsel *evsel)
> >       evsel__match(evsel, SOFTWARE, SW_TASK_CLOCK);
> > }
> > 
> > -bool evsel__fallback(struct evsel *evsel, int err, char *msg, size_t msgsize);
> > +bool evsel__fallback(struct evsel *evsel, struct target *target, int err,
> > +     char *msg, size_t msgsize);
> > int evsel__open_strerror(struct evsel *evsel, struct target *target,
> > int err, char *msg, size_t size);
> > 
> > -- 
> > 2.43.0.rc1.413.gea7ed67945-goog
> > 
> 

-- 

- Arnaldo

  reply	other threads:[~2023-12-05 15:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21  0:04 [RFC PATCH v2] perf evsel: Fallback to task-clock when not system wide Ian Rogers
2023-12-04 16:02 ` Ian Rogers
2023-12-04 22:55   ` Namhyung Kim
2023-12-05 11:21 ` Athira Rajeev
2023-12-05 15:25   ` Arnaldo Carvalho de Melo [this message]
2023-12-06  6:11     ` Athira Rajeev

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=ZW9A/jpVNdeNZYnh@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akaher@vmware.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=amakhalov@vmware.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=leo.yan@linaro.org \
    --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=ravi.bangoria@amd.com \
    --cc=sandipan.das@amd.com \
    --cc=yangjihong1@huawei.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.