From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>,
James Clark <james.clark@linaro.org>, Leo Yan <leo.yan@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
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>,
James Clark <james.clark@linaro.org>,
Ze Gao <zegao2021@gmail.com>, Weilin Wang <weilin.wang@intel.com>,
Dominique Martinet <asmadeus@codewreck.org>,
Jean-Philippe Romain <jean-philippe.romain@foss.st.com>,
Junhao He <hejunhao3@huawei.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
bpf@vger.kernel.org, Aditya Bodkhe <Aditya.Bodkhe1@ibm.com>,
Leo Yan <leo.yan@arm.com>, Atish Patra <atishp@rivosinc.com>
Subject: Re: [PATCH v5 3/4] perf record: Skip don't fail for events that don't open
Date: Fri, 10 Jan 2025 10:55:24 -0800 [thread overview]
Message-ID: <Z4FtHGBbCEeLQhAm@google.com> (raw)
In-Reply-To: <CAP-5=fUSfbZGNaUttM3UCzcrMzkkFAJVA8mheMKQ0nxNH_KuTg@mail.gmail.com>
On Thu, Jan 09, 2025 at 08:44:38PM -0800, Ian Rogers wrote:
> On Thu, Jan 9, 2025 at 5:25 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Thu, Jan 09, 2025 at 02:21:08PM -0800, Ian Rogers wrote:
> > > Whilst for many tools it is an expected behavior that failure to open
> > > a perf event is a failure, ARM decided to name PMU events the same as
> > > legacy events and then failed to rename such events on a server uncore
> > > SLC PMU. As perf's default behavior when no PMU is specified is to
> > > open the event on all PMUs that advertise/"have" the event, this
> > > yielded failures when trying to make the priority of legacy and
> > > sysfs/json events uniform - something requested by RISC-V and ARM. A
> > > legacy event user on ARM hardware may find their event opened on an
> > > uncore PMU which for perf record will fail. Arnaldo suggested skipping
> > > such events which this patch implements. Rather than have the skipping
> > > conditional on running on ARM, the skipping is done on all
> > > architectures as such a fundamental behavioral difference could lead
> > > to problems with tools built/depending on perf.
> > >
> > > An example of perf record failing to open events on x86 is:
> > > ```
> > > $ perf record -e data_read,cycles,LLC-prefetch-read -a sleep 0.1
> > > Error:
> > > Failure to open event 'data_read' on PMU 'uncore_imc_free_running_0' which will be removed.
> > > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (data_read).
> > > "dmesg | grep -i perf" may provide additional information.
> > >
> > > Error:
> > > Failure to open event 'data_read' on PMU 'uncore_imc_free_running_1' which will be removed.
> > > The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (data_read).
> > > "dmesg | grep -i perf" may provide additional information.
> > >
> > > Error:
> > > Failure to open event 'LLC-prefetch-read' on PMU 'cpu' which will be removed.
> > > The LLC-prefetch-read event is not supported.
> > > [ perf record: Woken up 1 times to write data ]
> > > [ perf record: Captured and wrote 2.188 MB perf.data (87 samples) ]
> >
> > I'm afraid this can be too noisy.
>
> The intention is to be noisy:
> 1) it matches the existing behavior, anything else is potentially a regression;
Well.. I think you're changing the behavior. :) Also currently it just
fails on the first event so it won't be too much noisy.
$ perf record -e data_read,data_write,LLC-prefetch-read -a sleep 0.1
event syntax error: 'data_read,data_write,LLC-prefetch-read'
\___ Bad event name
Unable to find event on a PMU of 'data_read'
Run 'perf list' for a list of valid events
Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
-e, --event <event> event selector. use 'perf list' to list available events
> 2) it only happens if trying to record on a PMU/event that doesn't
> support recording, something that is currently an error and so we're
> not motivated to change the behavior as no-one should be using it;
It was caught by Linus, so we know at least one (very important) user.
> 3) for the wildcard case the only offender is ARM's SLC PMU and the
> appropriate fix there has always been to make the CPU cycle's event
> name match the bus_cycles event name by calling it cpu_cycles -
> something that doesn't conflict with a core PMU event name, the thing
> that has introduced all these problems, patches, long email exchanges,
> unfixed inconsistencies, etc.. If the errors aren't noisy then there
> is little motivation for the ARM SLC PMU's event name to be fixed.
I understand your concern but I'm not sure it's the best way to fix the
issue.
James, Leo, is there any chance you can rename the SLC cycles event in
the kernel driver?
Thanks,
Namhyung
next prev parent reply other threads:[~2025-01-10 18:55 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 22:21 [PATCH v5 0/4] Prefer sysfs/JSON events also when no PMU is provided Ian Rogers
2025-01-09 22:21 ` [PATCH v5 1/4] perf evsel: Add pmu_name helper Ian Rogers
2025-01-09 22:21 ` [PATCH v5 2/4] perf stat: Fix find_stat for mixed legacy/non-legacy events Ian Rogers
2025-01-09 22:21 ` [PATCH v5 3/4] perf record: Skip don't fail for events that don't open Ian Rogers
2025-01-10 1:25 ` Namhyung Kim
2025-01-10 4:44 ` Ian Rogers
2025-01-10 18:55 ` Namhyung Kim [this message]
2025-01-10 19:18 ` Ian Rogers
2025-01-14 19:29 ` Namhyung Kim
2025-01-14 23:55 ` Ian Rogers
2025-01-15 22:14 ` Namhyung Kim
2025-01-15 22:40 ` Ian Rogers
2025-01-10 14:18 ` Arnaldo Carvalho de Melo
2025-01-10 16:42 ` Ian Rogers
2025-01-10 19:26 ` Namhyung Kim
2025-01-10 21:33 ` Ian Rogers
2025-01-13 20:51 ` Namhyung Kim
2025-01-13 23:04 ` Ian Rogers
2025-01-15 17:31 ` Namhyung Kim
2025-01-15 17:56 ` Ian Rogers
2025-01-29 21:24 ` Namhyung Kim
2025-01-09 22:21 ` [PATCH v5 4/4] perf parse-events: Reapply "Prefer sysfs/JSON hardware events over legacy" Ian Rogers
2025-01-10 19:40 ` Namhyung Kim
2025-01-10 19:52 ` Atish Kumar Patra
2025-01-13 20:56 ` Namhyung Kim
2025-01-10 22:15 ` Ian Rogers
2025-01-13 22:01 ` Namhyung Kim
2025-01-13 22:51 ` Ian Rogers
2025-01-14 2:31 ` Ian Rogers
2025-01-15 17:59 ` Namhyung Kim
2025-01-15 21:20 ` Ian Rogers
2025-01-29 21:55 ` Namhyung Kim
2025-01-30 1:16 ` Ian Rogers
2025-01-30 5:16 ` Namhyung Kim
2025-01-30 6:03 ` Ian Rogers
2025-01-31 22:28 ` Namhyung Kim
2025-01-30 6:12 ` Atish Kumar Patra
2025-01-31 22:42 ` Namhyung Kim
2025-02-01 8:45 ` Ian Rogers
2025-02-04 0:15 ` Namhyung Kim
2025-02-04 0:41 ` Ian Rogers
2025-02-05 1:57 ` Namhyung Kim
2025-02-05 4:48 ` Ian Rogers
2025-02-06 5:09 ` Namhyung Kim
2025-02-06 7:44 ` Ian Rogers
2025-02-07 4:44 ` Namhyung Kim
2025-02-07 6:15 ` Ian Rogers
2025-02-07 17:18 ` Atish Kumar Patra
2025-02-19 23:22 ` Namhyung Kim
2025-02-19 23:32 ` Ian Rogers
2025-02-03 5:47 ` Atish Kumar Patra
2025-01-29 22:05 ` [PATCH v5 0/4] Prefer sysfs/JSON events also when no PMU is provided Namhyung Kim
2025-01-30 17:46 ` 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=Z4FtHGBbCEeLQhAm@google.com \
--to=namhyung@kernel.org \
--cc=Aditya.Bodkhe1@ibm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=asmadeus@codewreck.org \
--cc=atishp@rivosinc.com \
--cc=bpf@vger.kernel.org \
--cc=hejunhao3@huawei.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jean-philippe.romain@foss.st.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=weilin.wang@intel.com \
--cc=zegao2021@gmail.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).