[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aee9254e-81c1-464a-8a28-f971615baffc@arm.com>
Date: Thu, 30 May 2024 13:48:38 +0100
From: James Clark <james.clark@....com>
To: Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Leo Yan <leo.yan@...ux.dev>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Dominique Martinet <asmadeus@...ewreck.org>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] perf evlist: Force adding default events only to core
PMUs
On 30/05/2024 06:35, Namhyung Kim wrote:
> On Wed, May 29, 2024 at 12:25 PM Ian Rogers <irogers@...gle.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
Powered by blists - more mailing lists