Re: CPUFREQ-CPUHOTPLUG: Possible circular locking dependency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Andrew Morton <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux