From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>, Kan Liang <kan.liang@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
Ravi Bangoria <ravi.bangoria@amd.com>,
Mark Rutland <mark.rutland@arm.com>,
James Clark <james.clark@arm.com>,
Kajol Jain <kjain@linux.ibm.com>,
Thomas Richter <tmricht@linux.ibm.com>,
Atish Patra <atishp@atishpatra.org>,
Palmer Dabbelt <palmer@rivosinc.com>,
Mingwei Zhang <mizhang@google.com>
Subject: Re: [PATCH 5/8] perf tools: Detect missing kernel features properly
Date: Tue, 1 Oct 2024 14:32:32 -0700 [thread overview]
Message-ID: <ZvxqcEIVELw9Uets@google.com> (raw)
In-Reply-To: <CAP-5=fVrptOSOK+sBo0rHR1QWQ0i1WigMaFRy=So-HATKr=R9A@mail.gmail.com>
On Tue, Oct 01, 2024 at 10:53:02AM -0700, Ian Rogers wrote:
> On Mon, Sep 30, 2024 at 5:20 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > The evsel__detect_missing_features() is to check if the attributes of
> > the evsel is supported or not. But it checks the attribute based on the
> > given evsel, it might miss something if the attr doesn't have the bit or
> > give incorrect results if the event is special.
> >
> > Also it maintains the order of the feature that was added to the kernel
> > which means it can assume older features should be supported once it
> > detects the current feature is working. To minimized the confusion and
> > to accurately check the kernel features, I think it's better to use a
> > software event and go through all the features at once.
> >
> > Also make the function static since it's only used in evsel.c.
> >
> > Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> > ---
> > tools/perf/util/evsel.c | 345 +++++++++++++++++++++++++++++-----------
> > tools/perf/util/evsel.h | 1 -
> > 2 files changed, 249 insertions(+), 97 deletions(-)
> >
> > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > index f202d28147d62a44..32e30c293d0c6198 100644
> > --- a/tools/perf/util/evsel.c
> > +++ b/tools/perf/util/evsel.c
> > @@ -20,6 +20,7 @@
> > #include <linux/zalloc.h>
> > #include <sys/ioctl.h>
> > #include <sys/resource.h>
> > +#include <sys/syscall.h>
> > #include <sys/types.h>
> > #include <dirent.h>
> > #include <stdlib.h>
> > @@ -2150,120 +2151,272 @@ int evsel__prepare_open(struct evsel *evsel, struct perf_cpu_map *cpus,
> > return err;
> > }
> >
> > -bool evsel__detect_missing_features(struct evsel *evsel)
> > +static bool has_attr_feature(struct perf_event_attr *attr, unsigned long flags)
> > {
> > + int fd = syscall(SYS_perf_event_open, attr, /*pid=*/0, /*cpu=*/-1,
> > + /*group_fd=*/-1, flags);
> > + close(fd);
> > +
> > + if (fd < 0) {
> > + attr->exclude_kernel = 1;
> > +
> > + fd = syscall(SYS_perf_event_open, attr, /*pid=*/0, /*cpu=*/-1,
> > + /*group_fd=*/-1, flags);
> > + close(fd);
> > + }
> > +
> > + if (fd < 0) {
> > + attr->exclude_hv = 1;
> > +
> > + fd = syscall(SYS_perf_event_open, attr, /*pid=*/0, /*cpu=*/-1,
> > + /*group_fd=*/-1, flags);
> > + close(fd);
> > + }
> > +
> > + if (fd < 0) {
> > + attr->exclude_guest = 1;
> > +
> > + fd = syscall(SYS_perf_event_open, attr, /*pid=*/0, /*cpu=*/-1,
> > + /*group_fd=*/-1, flags);
> > + close(fd);
> > + }
> > +
> > + attr->exclude_kernel = 0;
> > + attr->exclude_guest = 0;
> > + attr->exclude_hv = 0;
> > +
> > + return fd >= 0;
> > +}
> > +
> > +static void evsel__detect_missing_brstack_features(struct evsel *evsel)
>
> In the future could other PMU specific unsupported features be added
> not just brstack? Perhaps evsel__detect_missing_pmu_features would
> better capture that.
Yep, sounds reasonable. I think we can add that if we have another
thing to check.
>
> > +{
> > + static bool detection_done = false;
> > + struct perf_event_attr attr = {
> > + .type = evsel->core.attr.type,
> > + .config = evsel->core.attr.config,
> > + .disabled = 1,
> > + .sample_type = PERF_SAMPLE_BRANCH_STACK,
> > + .sample_period = 1000,
> > + };
> > + int old_errno;
> > +
> > + if (detection_done)
> > + return;
> > +
> > + old_errno = errno;
> > +
> > /*
> > * Must probe features in the order they were added to the
> > - * perf_event_attr interface.
> > + * perf_event_attr interface. These are PMU specific limitation
> > + * so we can detect with the given hardware event and stop on the
> > + * first one succeeded.
> > */
> > - if (!perf_missing_features.branch_counters &&
> > - (evsel->core.attr.branch_sample_type & PERF_SAMPLE_BRANCH_COUNTERS)) {
> > - perf_missing_features.branch_counters = true;
> > - pr_debug2("switching off branch counters support\n");
> > - return true;
> > - } else if (!perf_missing_features.read_lost &&
> > - (evsel->core.attr.read_format & PERF_FORMAT_LOST)) {
> > - perf_missing_features.read_lost = true;
> > - pr_debug2("switching off PERF_FORMAT_LOST support\n");
> > +
> > + /* Please add new feature detection here. */
> > +
> > + attr.branch_sample_type = PERF_SAMPLE_BRANCH_COUNTERS;
> > + if (has_attr_feature(&attr, /*flags=*/0))
> > + goto found;
> > + perf_missing_features.branch_counters = true;
>
> It feels like these global variables should be part of the PMU state.
> There is already perf_pmu.missing_features.
You're right. But I think this is kinda global feature unless we have
different PMUs that provide different branch sampling capability. It's
just the feature test requires a specific PMU and event. But it'd be
better putting this into struct perf_pmu later.
Kan, can you confirm if Intel hybrid systems have the same branch stack
sampling capabilities on both cores?
Thanks,
Namhyung
next prev parent reply other threads:[~2024-10-01 21:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-01 0:20 [PATCHSET 0/8] perf tools: Do not set attr.exclude_guest by default (v4) Namhyung Kim
2024-10-01 0:20 ` [PATCH 1/8] perf tools: Add fallback for exclude_guest Namhyung Kim
2024-10-01 17:41 ` Ian Rogers
2024-10-01 0:20 ` [PATCH 2/8] perf tools: Don't set attr.exclude_guest by default Namhyung Kim
2024-10-01 17:43 ` Ian Rogers
2024-10-01 0:20 ` [PATCH 3/8] perf tools: Simplify evsel__add_modifier() Namhyung Kim
2024-10-01 17:44 ` Ian Rogers
2024-10-01 0:20 ` [PATCH 4/8] perf tools: Do not set exclude_guest for precise_ip Namhyung Kim
2024-10-01 17:46 ` Ian Rogers
2024-10-01 0:20 ` [PATCH 5/8] perf tools: Detect missing kernel features properly Namhyung Kim
2024-10-01 17:53 ` Ian Rogers
2024-10-01 21:32 ` Namhyung Kim [this message]
2024-10-15 4:19 ` Ravi Bangoria
2024-10-16 4:49 ` Namhyung Kim
2024-10-01 0:20 ` [PATCH 6/8] perf tools: Move x86__is_amd_cpu() to util/env.c Namhyung Kim
2024-10-01 16:03 ` Liang, Kan
2024-10-01 22:39 ` Namhyung Kim
2024-10-01 0:20 ` [PATCH 7/8] perf tools: Check fallback error and order Namhyung Kim
2024-10-01 18:00 ` Ian Rogers
2024-10-01 21:36 ` Namhyung Kim
2024-10-01 22:21 ` Ian Rogers
2024-10-03 17:06 ` Namhyung Kim
2024-10-03 17:32 ` Ian Rogers
2024-10-03 22:38 ` Namhyung Kim
2024-10-14 19:22 ` Namhyung Kim
2024-10-15 4:21 ` Ravi Bangoria
2024-10-16 4:33 ` Namhyung Kim
2024-10-16 4:47 ` Ian Rogers
2024-10-01 0:20 ` [PATCH 8/8] perf record: Just use "cycles:P" as the default event Namhyung Kim
2024-10-01 18:00 ` Ian Rogers
2024-10-01 17:46 ` [PATCHSET 0/8] perf tools: Do not set attr.exclude_guest by default (v4) Liang, Kan
2024-10-01 21:19 ` Namhyung Kim
2024-10-02 9:49 ` James Clark
2024-10-02 18:29 ` Namhyung Kim
2024-10-04 15:40 ` James Clark
2024-10-04 19:17 ` Namhyung Kim
2024-10-15 4:25 ` Ravi Bangoria
-- strict thread matches above, loose matches on Subject: below --
2024-09-04 6:41 [RFC/PATCHSET 0/8] perf tools: Do not set attr.exclude_guest by default (v2) Namhyung Kim
2024-09-04 6:41 ` [PATCH 5/8] perf tools: Detect missing kernel features properly Namhyung Kim
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=ZvxqcEIVELw9Uets@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=atishp@atishpatra.org \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=mizhang@google.com \
--cc=palmer@rivosinc.com \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=tmricht@linux.ibm.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.