Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> > Even with complex inter-subsystem interactions, hotplugging could be 
> > effectively and scalably controlled via a self-recursive per-CPU 
> > mutex, and a pointer to it embedded in task_struct:

> So what I would propose is that rather than going ahead and piling 
> more complexity on top of the existing poo-pile in an attempt to make 
> it seem to work, we should simply rip all the cpu-hotplug locking out 
> of cpufreq (there's a davej patch for that in -mm) and then just redo 
> it all in an organised fashion.

actually, that's precisely what i'm suggesting too, i wrote it to 
Gautham in one of the previous mails:

|| that would flatten the whole locking. Only one kind of lock taken, 
|| recursive and scalable.
||
|| 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.

no other locking, only the CPU hotplug lock and the (existing) ability 
to 'do stuff' with nothing else running on any other CPU.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/