Messages in this thread | | | Date | Thu, 30 Nov 2006 17:49:01 +0530 | From | Gautham R Shenoy <> | Subject | Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency |
| |
On Thu, Nov 30, 2006 at 12:53:27PM +0100, Ingo Molnar wrote: > > * Gautham R Shenoy <ego@in.ibm.com> wrote: > > > This is what is currently being done by cpufreq: > > ok! > > > a) get_some_cpu_hotplug_protection() [use either some global mechanism > > or a persubsystem mutex] > > this bit is wrong i think. Any reason why it's not a per-CPU (but > otherwise global) array of mutexes that controls CPU hotplug - as per my > previous mail? > > that would flatten the whole locking. Only one kind of lock taken, > recursive and scalable.
I had posted one such recursive scalable version which can be found here http://lkml.org/lkml/2006/10/26/73
I remember cc'ing you.
Yeah, it looks complicated and big, but then I did not want to add another field to the task struct as one such attempt had already been frowned upon ( I think long back Ashok posted it)
So I ended up writing the whole read/write lock/unlock code myself.
It's a RCU based lock, extremely light on the read side, but costly for the writers since it does a synchronize_sched.
And yeah, it's partial towards the readers but with an additional field in the task struct we can have a fair implementation.
Besides, an unfair cpu_hotplug_lock won't work since a process doing a sched_getaffinity in a forever_while loop can prevent any hotplug from happening.
> > Then the mechanism that changes CPU frequency should take all these > hotplug locks on all (online) CPUs, and then first stop all processing > on all CPUs, and then do the frequency change, atomically. This is with > interrupts disabled everywhere /first/, and /without any additional > locking/. That would prevent any sort of interaction from other CPUs - > they'd all be sitting still with interrupts disabled. >
Yup.
> Ingo
regards gautham. -- Gautham R Shenoy Linux Technology Center IBM India. "Freedom comes with a price tag of responsibility, which is still a bargain, because Freedom is priceless!" - 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/
| |