[SRU][N:linux-aws][PATCH 2/2] perf/core: Reduce PMU access to adjust sample freq

Philip Cox philip.cox at canonical.com
Wed Apr 2 14:48:48 UTC 2025


From: Namhyung Kim <namhyung at kernel.org>

BugLink: https://bugs.launchpad.net/bugs/2106004

In perf_adjust_freq_unthr_context(), it first starts the event and then
stop unnecessarily to adjust the sampling frequency if the event is
throttled.

For a throttled non-frequency event, it doesn't have a freq so no need
to adjust.  Just starting the event would be ok.

For a frequency event, whether it's throttled or not, it needs to stop
before adjusting the frequency.  That means it should not start the
even if it was throttled.  I tried to skip calling the stop callback,
but it didn't work well since the event count might not be up to date.
It should call the stop callback with PERF_EF_UPDATE anyway.

However not calling start would prevent unnecessary MSR accesses (which
can be costly) for already stopped events as stop state is saved in the
hw config.

Signed-off-by: Namhyung Kim <namhyung at kernel.org>
Signed-off-by: Ingo Molnar <mingo at kernel.org>
Reviewed-by: Ian Rogers <irogers at google.com>
Reviewed-by: Kan Liang <kan.liang at linux.intel.com>
Link: https://lore.kernel.org/r/20240207050545.2727923-2-namhyung@kernel.org
(cherry picked from commit f38628b06c36222367e26820879789ae59e49f60)
Signed-off-by: Philip Cox <philip.cox at canonical.com>
---
 kernel/events/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5546618bab3e..4a830f180d60 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4156,7 +4156,8 @@ static void perf_adjust_freq_unthr_events(struct list_head *event_list)
 		if (hwc->interrupts == MAX_INTERRUPTS) {
 			hwc->interrupts = 0;
 			perf_log_throttle(event, 1);
-			event->pmu->start(event, 0);
+			if (!event->attr.freq || !event->attr.sample_freq)
+				event->pmu->start(event, 0);
 		}
 
 		if (!event->attr.freq || !event->attr.sample_freq)
-- 
2.43.0




More information about the kernel-team mailing list