From: James Clark <james.clark@arm.com>
To: Namhyung Kim <namhyung@kernel.org>, Ian Rogers <irogers@google.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Leo Yan <leo.yan@linux.dev>,
Linus Torvalds <torvalds@linux-foundation.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>,
Dominique Martinet <asmadeus@codewreck.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] perf evlist: Force adding default events only to core PMUs
Date: Thu, 30 May 2024 13:48:38 +0100 [thread overview]
Message-ID: <aee9254e-81c1-464a-8a28-f971615baffc@arm.com> (raw)
In-Reply-To: <CAM9d7chV8YOCj8=SGs0f60UGtf+N2+X=U+Brg246bFoPXBXS+g@mail.gmail.com>
On 30/05/2024 06:35, Namhyung Kim wrote:
> On Wed, May 29, 2024 at 12:25 PM Ian Rogers <irogers@google.com> wrote:
>> We can fix the arm_dsu bug by renaming cycles there. If that's too
>> hard to land, clearing up ambiguity by adding a PMU name has always
>> been the way to do this. My preference for v6.10 is revert the revert,
>> then add either a rename of the arm_dsu event and/or the change here.
>>
>> We can make perf record tolerant and ignore opening events on PMUs
>> that don't support sampling, but I think it is too big a thing to do
>> for v6.10.
>
> How about adding a flag to parse_event_option_args so that we
> can check if it's for sampling events. And then we might skip
> uncore PMUs easily (assuming arm_dsu PMU is uncore).
It's uncore yes.
Couldn't we theoretically have a core PMU that still doesn't support
sampling though? And then we'd end up in the same situation. Attempting
to open the event is the only sure way of knowing, rather than trying to
guess with some heuristic in userspace?
Maybe a bit too hypothetical but still worth considering.
>
> It might not be a perfect solution but it could be a simple one.
> Ideally I think it'd be nice if the kernel exports more information
> about the PMUs like sampling and exclude capabilities.
> > Thanks,
> Namhyung
That seems like a much better suggestion. Especially with the ever
expanding retry/fallback mechanism that can never really take into
account every combination of event attributes that can fail.
James
next prev parent reply other threads:[~2024-05-30 12:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-25 15:29 [PATCH v1] perf evlist: Force adding default events only to core PMUs Ian Rogers
2024-05-25 16:43 ` Linus Torvalds
2024-05-25 21:14 ` Linus Torvalds
2024-05-27 10:58 ` Leo Yan
2024-05-28 5:36 ` Ian Rogers
2024-05-28 17:00 ` Linus Torvalds
2024-05-28 17:39 ` Ian Rogers
2024-05-28 18:12 ` Linus Torvalds
2024-05-28 18:58 ` Ian Rogers
2024-05-28 19:42 ` Linus Torvalds
2024-05-28 20:03 ` Ian Rogers
2024-05-28 20:33 ` Linus Torvalds
2024-05-28 21:37 ` Ian Rogers
2024-05-28 21:42 ` Linus Torvalds
2024-05-28 19:44 ` Arnaldo Carvalho de Melo
2024-05-28 19:51 ` Ian Rogers
2024-05-29 14:50 ` James Clark
2024-05-29 17:33 ` Ian Rogers
2024-05-30 15:37 ` James Clark
2024-05-30 16:14 ` Ian Rogers
2024-05-29 18:44 ` Arnaldo Carvalho de Melo
2024-05-29 19:25 ` Ian Rogers
2024-05-30 5:35 ` Namhyung Kim
2024-05-30 12:48 ` James Clark [this message]
2024-05-30 13:46 ` Ian Rogers
2024-05-30 22:51 ` Namhyung Kim
2024-06-05 20:29 ` Namhyung Kim
2024-06-05 23:02 ` Ian Rogers
2024-06-06 7:09 ` Namhyung Kim
2024-06-06 9:42 ` James Clark
2024-06-06 13:51 ` Arnaldo Carvalho de Melo
2024-06-07 6:10 ` Namhyung Kim
2024-06-06 13:47 ` Arnaldo Carvalho de Melo
2024-05-28 20:00 ` Linus Torvalds
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=aee9254e-81c1-464a-8a28-f971615baffc@arm.com \
--to=james.clark@arm.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=asmadeus@codewreck.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linux.dev \
--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=torvalds@linux-foundation.org \
/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).