Messages in this thread | | | Date | Tue, 2 Jun 2015 11:09:56 +0530 | From | Viresh Kumar <> | Subject | Re: [RFC PATCH] cpufreq/hotplug: Fix cpu-hotplug cpufreq race conditions |
| |
On 02-06-15, 11:01, Preeti U Murthy wrote: > How will a policy lock help here at all, when cpus from multiple > policies are calling into __cpufreq_governor() ? How will a policy lock > serialize their entry into cpufreq_governor_dbs() ?
So different policies don't really depend on each other. The only thing common to them are the governor's sysfs files (only if governor-per-policy isn't set, i.e. in your case). Those sysfs files and their kernel counterpart variables aren't touched unless all the policies have EXITED. All these START/STOP calls touch only the data relevant to those policies only.
In case of per-policy governors, even those sysfs files are separate for each policy.
And so a policy lock should be sufficient, rest should be handled within the governors with locks or whatever.
> > These band-aid wouldn't take us anywhere. > > Why do you say that the approach mentioned in this patch is a bandaid ? > The patch ensures that there are no interruptions in a logical sequence > of calls into cpufreq_governor_dbs(), as it should be.
Because this happened as we are forced to drop the policy-locks. That's the real problem. This whole thing should be performed under locks, instead of setting variables to mark governor busy under locks.
-- viresh
| |