| Message ID | 20130906195353.26919.76123.stgit@srivatsabhat.in.ibm.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On 7 September 2013 01:23, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > Commit "cpufreq: serialize calls to __cpufreq_governor()" had been a temporary > and partial solution to the race condition between writing to a cpufreq sysfs > file and taking a CPU offline. Now that we have a proper and complete solution > to that problem, remove the temporary fix. > > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > --- I would still vote for keeping this code or reverting this patch of yours.. As there might be other scenarios, than hotplug races, where this serialization would be useful.. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/10/2013 12:39 PM, Viresh Kumar wrote: > On 7 September 2013 01:23, Srivatsa S. Bhat > <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> Commit "cpufreq: serialize calls to __cpufreq_governor()" had been a temporary >> and partial solution to the race condition between writing to a cpufreq sysfs >> file and taking a CPU offline. Now that we have a proper and complete solution >> to that problem, remove the temporary fix. >> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> --- > > I would still vote for keeping this code or reverting this patch of yours.. > As there might be other scenarios, than hotplug races, where this serialization > would be useful.. > I would say it would be better to first explain those scenarios in detail, and then justify why this solution is the best one. Without that, it starts appearing more like premature optimization... and we all know the mess that it can lead to ;-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index c2eb413..9909789 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1783,15 +1783,13 @@ static int __cpufreq_governor(struct cpufreq_policy *policy, policy->cpu, event); mutex_lock(&cpufreq_governor_lock); - if (policy->governor_busy - || (policy->governor_enabled && event == CPUFREQ_GOV_START) + if ((policy->governor_enabled && event == CPUFREQ_GOV_START) || (!policy->governor_enabled && (event == CPUFREQ_GOV_LIMITS || event == CPUFREQ_GOV_STOP))) { mutex_unlock(&cpufreq_governor_lock); return -EBUSY; } - policy->governor_busy = true; if (event == CPUFREQ_GOV_STOP) policy->governor_enabled = false; else if (event == CPUFREQ_GOV_START) @@ -1820,9 +1818,6 @@ static int __cpufreq_governor(struct cpufreq_policy *policy, ((event == CPUFREQ_GOV_POLICY_EXIT) && !ret)) module_put(policy->governor->owner); - mutex_lock(&cpufreq_governor_lock); - policy->governor_busy = false; - mutex_unlock(&cpufreq_governor_lock); return ret; } diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index cca885d..d568f39 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -76,7 +76,6 @@ struct cpufreq_policy { struct cpufreq_governor *governor; /* see below */ void *governor_data; bool governor_enabled; /* governor start/stop flag */ - bool governor_busy; struct work_struct update; /* if update_policy() needs to be * called, but you're in IRQ context */
Commit "cpufreq: serialize calls to __cpufreq_governor()" had been a temporary and partial solution to the race condition between writing to a cpufreq sysfs file and taking a CPU offline. Now that we have a proper and complete solution to that problem, remove the temporary fix. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- drivers/cpufreq/cpufreq.c | 7 +------ include/linux/cpufreq.h | 1 - 2 files changed, 1 insertion(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html