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 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.