From bcc5be7535403c84962d2e149048d20d17c8d4eb Mon Sep 17 00:00:00 2001 From: Cosmin Tanislav Date: Tue, 16 Apr 2024 21:01:49 +0300 Subject: [PATCH] Reapply "cpufreq: schedutil: Always process remote callback with slow switching" This reverts commit f7b03e2cd6f829a4fe1be4284ce5b9098eec4f74. --- kernel/sched/cpufreq_schedutil.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index cca814d5670c..e3d779620708 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -105,13 +105,18 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) * * However, drivers cannot in general deal with cross-cpu * requests, so while get_next_freq() will work, our - * sugov_update_commit() call may not. + * sugov_update_commit() call may not for the fast switching platforms. * * Hence stop here for remote requests if they aren't supported * by the hardware, as calculating the frequency is pointless if * we cannot in fact act on it. + * + * For the slow switching platforms, the kthread is always scheduled on + * the right set of CPUs and any CPU can find the next frequency and + * schedule the kthread. */ - if (!cpufreq_can_do_remote_dvfs(sg_policy->policy)) + if (sg_policy->policy->fast_switch_enabled && + !cpufreq_can_do_remote_dvfs(sg_policy->policy)) return false; if (sg_policy->work_in_progress) -- 2.20.1