On 19-03-21, 15:35, Rafael J. Wysocki wrote: > On Friday, March 19, 2021 8:37:51 AM CET Viresh Kumar wrote: > > On 18-03-21, 22:28, Peter Zijlstra wrote: > > > Also, is there a lock order comment in cpufreq somewhere? > > > > I don't think so. > > > > > I tried > > > following it, but eventually gave up and figured 'asking' lockdep was > > > far simpler. > > > > This will get called from CPU's online/offline path at worst, nothing more. > > I'm not sure if I understand you correctly, but for completeness the callback > is also set/unset on driver registration and governor switch.
Right, I believe that those cases don't have any specific locking constraints and so scheduler code doesn't need to worry about them. cpuslocked stuff needs to be considered though. > > > +static void cpufreq_update_optimize(void) > > > +{ > > > + struct update_util_data *data; > > > + cpu_util_update_f func = NULL, dfunc; > > > + int cpu; > > > + > > > + for_each_online_cpu(cpu) { > > > + data = per_cpu(cpufreq_update_util_data, cpu); > > > + dfunc = data ? READ_ONCE(data->func) : NULL; > > > + > > > + if (dfunc) { > > > + if (!func) > > > + func = dfunc; > > > + else if (func != dfunc) > > > + return; > > > + } else if (func) > > > + return; > > > + } > > > > So there is nothing cpufreq specific IIRC that can help make this better, > > this > > is basically per policy. > > Well, in some cases the driver knows that there will never be more that 1 CPU > per policy and so schedutil will never use the "shared" variant. > > For instance, with intel_pstate all CPUs will always use the same callback. Right, only for single policy cases we can have some optimization (though I don't feel its worth here) as this isn't going to happen in hotpath. -- viresh