[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230605092731.GZ4253@hirez.programming.kicks-ass.net>
Date: Mon, 5 Jun 2023 11:27:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Ravi Bangoria <ravi.bangoria@....com>, jolsa@...nel.org,
irogers@...gle.com, bp@...en8.de, adrian.hunter@...el.com,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
"linux-samsung-soc@...r.kernel.org"
<linux-samsung-soc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>
Subject: Re: [REGRESSION][BISECT] perf/core: Remove pmu linear searching code
On Mon, Jun 05, 2023 at 08:10:15AM +0100, Mark Rutland wrote:
> How does this work on x86? Do you have pseudo-PMUs for PERF_TYPE_HARDWARE and
> PERF_TYPE_RAW ?
Generic code maps TYPE_HARDWARE and TYPE_HW_CACHE to TYPE_RAW for a
first go, only if that fails it will try the actual type.
And x86 has the (first) CPU PMU has TYPE_RAW, on hybrid, it will
transparently pick the right actual PMU.
That said; given that this commit has been tagged twice now, I suppose I
should go revert it and we'll try again after a more thorough audit.
Powered by blists - more mailing lists