![]() | |||||||||||
Messages in this thread |
On Wed, Jul 26, 2006 at 03:40:07PM +0200, Arjan van de Ven wrote: > Subject: Reorganize the cpufreq cpu hotplug locking to not be totally bizare > From: Arjan van de Ven <arjan@linux.intel.com> > > The patch below moves the cpu hotplugging higher up in the cpufreq > layering; this is needed to avoid recursive taking of the cpu hotplug > lock and to otherwise detangle the mess. > > The new rules are: > 1. you must do lock_cpu_hotplug() around the following functions: > __cpufreq_driver_target > __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only) > __cpufreq_set_policy > 2. governer methods (.governer) must NOT take the lock_cpu_hotplug() > lock in any way; they are called with the lock taken already > 3. if your governer spawns a thread that does things, like calling > __cpufreq_driver_target, your thread must honor rule #1. > 4. the policy lock and other cpufreq internal locks nest within > the lock_cpu_hotplug() lock. > > I'm not entirely happy about how the __cpufreq_governor rule ended up > (conditional locking rule depending on the argument) but basically all > callers pass this as a constant so it's not too horrible. > > The patch also removes the cpufreq_governor() function since during the > locking audit it turned out to be entirely unused (so no need to fix it) > > The patch works on my testbox, but it could use more testing > (otoh... it can't be much worse than the current code) > > Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Looks sensible to me. Assuming it passes testing.. Signed-off-by: Dave Jones <davej@redhat.com> Linus ? Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-07-26 17:55 [from the cache] ©2003-2008 | |||||||||||