On Thu, Nov 30, 2006 at 12:53:27PM +0100, Ingo Molnar wrote: > > * Gautham R Shenoy <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
