From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
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>,
Athira Rajeev <atrajeev@linux.vnet.ibm.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: [RFC/PATCHSET 0/8] perf tools: Do not set attr.exclude_guest by default (v2)
Date: Wed, 4 Sep 2024 10:46:04 -0700 [thread overview]
Message-ID: <Ztic3BR4UUdhIVrq@google.com> (raw)
In-Reply-To: <CAP-5=fU5UeHER5hPAUhq_9_fSUR9okp_i0sOk_E7Q_aZkvo+DQ@mail.gmail.com>
Hi Ian,
On Wed, Sep 04, 2024 at 09:36:02AM -0700, Ian Rogers wrote:
> On Tue, Sep 3, 2024 at 11:41 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Hello,
> >
> > I found perf tools set exclude_guest bit inconsistently. It used to
> > set the bit but now the default event for perf record doesn't. So I'm
> > wondering why we want the bit in the first place.
> >
> > Actually it's not good for PMUs don't support any exclusion like AMD
> > IBS because it disables new features after the exclude_guest due to
> > the missing feature detection logic.
>
> I think trying to clean this up is good but there's a wac-a-moie
> problem whenever a default or fallback is changed - it can break a
> hard to test platform in unthought of ways. I wonder if we can expand
> PMU testing to at least capture the differences in behavior. For
Right, that's why I use a software event to test kernel features and
separate branch stack, precise_ip and excludes testing.
> example, pick an event that works, like legacy cycles, then increase
> the precision to 3 and the event should either open again or fail with
> EINVAL, if it opens then it should count. Similarly for the exclude_*
But sometimes precision and exclude_* interfere each other. AMD IBS
accepts precise_ip up to 2 but it'd fail if exclude_guest is set. And
sometimes the same PMU requires different exclude bits. For instance,
Intel branch stack sampling needs exclude_hv as well as exclude_kernel
for regular users, but normally it is enough to have exclude_kernel
for other events.
I agree that we need to save this info to per-PMU and reuse it for
other events. Actually I tried this but failed to get it working.
IIRC sometimes legacy events don't have evsel->pmu and looking up a
PMU for the evsel failed to get a correct PMU. Also I couldn't come
up with an absolute way to make sure if it checks the PMU features
100% correct. I think I need to add something to the kernel to show
supported (and required?) PMU exclude_* capabilities.
Maybe we can revisit this later, but having the missing kernel feature
checks separate from the PMU specific checks is an improvement IMHO.
Also having another fallback for exclude_guest would fix an existing
problem on Apple M1.
> bits. I think some PMUs don't behave like they should and we can add
> ifs to the test to capture these behaviours - for example an
> exclude_.. is accepted for an event but then the event doesn't count
> if the bit is set. There are many cases where a large group of events
So I want to start from no exclude_* and to add a bit at a time until
the PMU accepts the event so that it won't have unnecessary bits.
Thanks,
Namhyung
> will cause the group to stop counting, in metrics we work around this
> with grouping flags for the metric:
> https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/pmu-events.h?h=perf-tools-next#n16
> but these shouldn't be necessary as the PMU kernel driver should
> reject the perf_event_open.
>
> Thanks,
> Ian
>
> > v2 changes)
> > * update the missing feature detection logic
> > * separate exclude_hv fallback
> > * add new fallback for exclude_guest
> >
> > v1) https://lore.kernel.org/lkml/20240902014621.2002343-1-namhyung@kernel.org/
> >
> > AFAIK it doesn't matter for the most cases but perf kvm. If users
> > need to set the bit, they can still use :H modifier. For vPMU pass-
> > through or Apple M1, it'd add the exclude_guest during the fallback
> > logic. Please let me know if it's ok for you.
> >
> > The code is available at 'perf/exclude-v2' branch in
> > git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> >
> > Thanks,
> > Namhyung
> >
> >
> > Namhyung Kim (8):
> > perf tools: Don't set attr.exclude_guest by default
> > perf tools: Simplify evsel__add_modifier()
> > perf stat: Add --exclude-guest option
> > perf tools: Do not set exclude_guest for precise_ip
> > perf tools: Detect missing kernel features properly
> > perf tools: Separate exclude_hv fallback
> > perf tools: Add fallback for exclude_guest
> > perf tools: Check fallback error and order
> >
> > tools/perf/Documentation/perf-stat.txt | 7 +
> > tools/perf/builtin-kvm.c | 1 +
> > tools/perf/builtin-stat.c | 2 +
> > tools/perf/dlfilters/dlfilter-test-api-v0.c | 2 +-
> > tools/perf/dlfilters/dlfilter-test-api-v2.c | 2 +-
> > tools/perf/tests/attr/test-record-dummy-C0 | 2 +-
> > tools/perf/tests/parse-events.c | 30 +-
> > tools/perf/util/evsel.c | 393 ++++++++++++++------
> > tools/perf/util/evsel.h | 1 -
> > tools/perf/util/parse-events.c | 6 +-
> > tools/perf/util/util.c | 10 +-
> > tools/perf/util/util.h | 3 +
> > 12 files changed, 322 insertions(+), 137 deletions(-)
> >
> > --
> > 2.46.0.469.g59c65b2a67-goog
> >
prev parent reply other threads:[~2024-09-04 17:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
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 1/8] perf tools: Don't set attr.exclude_guest by default Namhyung Kim
2024-09-04 13:07 ` Arnaldo Carvalho de Melo
2024-09-04 15:43 ` Namhyung Kim
2024-09-04 6:41 ` [PATCH 2/8] perf tools: Simplify evsel__add_modifier() Namhyung Kim
2024-09-04 6:41 ` [PATCH 3/8] perf stat: Add --exclude-guest option Namhyung Kim
2024-09-04 6:41 ` [PATCH 4/8] perf tools: Do not set exclude_guest for precise_ip Namhyung Kim
2024-09-04 6:41 ` [PATCH 5/8] perf tools: Detect missing kernel features properly Namhyung Kim
2024-09-04 6:41 ` [PATCH 6/8] perf tools: Separate exclude_hv fallback Namhyung Kim
2024-09-04 6:41 ` [PATCH 7/8] perf tools: Add fallback for exclude_guest Namhyung Kim
2024-09-04 13:28 ` James Clark
2024-09-04 13:29 ` James Clark
2024-09-04 13:36 ` James Clark
2024-09-04 15:52 ` Namhyung Kim
2024-09-04 6:41 ` [PATCH 8/8] perf tools: Check fallback error and order Namhyung Kim
2024-09-04 16:19 ` Ian Rogers
2024-09-04 18:15 ` Namhyung Kim
2024-09-04 16:36 ` [RFC/PATCHSET 0/8] perf tools: Do not set attr.exclude_guest by default (v2) Ian Rogers
2024-09-04 17:46 ` Namhyung Kim [this message]
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=Ztic3BR4UUdhIVrq@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=atishp@atishpatra.org \
--cc=atrajeev@linux.vnet.ibm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).