On Wed, Jul 26, 2017 at 02:52:32PM +0530, Viresh Kumar wrote:
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index 45fcf21ad685..bb834747e49b 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -72,10 +72,15 @@ static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
/************************ Governor internals ***********************/
-static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) +static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time,
int target_cpu)
{ s64 delta_ns;
- /* Don't allow remote callbacks */
So I think you can reduce confusion in general if we extend this comment somewhat.
/* * Since cpufreq_update_util() is called with rq->lock held for * the @target_cpu, our per-cpu data is fully serialized. * * However, drivers cannot in general deal with cross-cpu * requests, so while get_next_freq() will work, our * sugov_update_commit() -> cpufreq_driver_fast_switch() * call will not. * * Hence stop here for remote requests, as calculating the * frequency is pointless if we cannot in fact act on it. */
- if (smp_processor_id() != target_cpu)
return false;
- if (sg_policy->work_in_progress) return false;