[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241218135229.GE2354@noisy.programming.kicks-ass.net>
Date: Wed, 18 Dec 2024 14:52:29 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: mingo@...hat.com, namhyung@...nel.org, acme@...nel.org,
eranian@...gle.com, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
irogers@...gle.com, adrian.hunter@...el.com,
kan.liang@...ux.intel.com, tglx@...utronix.de, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
santosh.shukla@....com, ananth.narayan@....com,
sandipan.das@....com
Subject: Re: [PATCH v3 08/10] perf/core: Introduce pmu->adjust_period()
callback
On Tue, Dec 10, 2024 at 09:34:47AM +0000, Ravi Bangoria wrote:
> Many hardware PMUs have constraints about sample period. For ex, minimum
> supported sample period for IBS Op PMU is 0x90, the sample period must
> be multiple of 0x10 for IBS Fetch and IBS Op.
>
> Add an optional callback adjust_period() to struct PMU to allow PMU
> specific drivers to adjust sample period calculated by generic code.
> This will ensure the sample_period value will always be valid and no
> additional code is required in PMU specific drivers to re-adjust the
> period.
And not a word about pmu::check_period() and x86_pmu::limit_period() :-(
Please explain why that can't be made to work nor adapted.
Powered by blists - more mailing lists