| |||||||||||||
SMP alternativesSMP alternativesPosted Dec 15, 2005 9:44 UTC (Thu) by dw (subscriber, #12017)Parent article: SMP alternatives
Please excuse my ignorance of kernel development, but I don't understand how this can be made to work safely. I am not sure under which conditions CPU hotplug events are processed, but I would imagine that at that time numerous locks in the kernel would be in the locked state.
If the CPU hotplug code causes the unlock functions to become a NOOP, then after the event has been processed, any scheduled tasks that perform an unlock of an existing lock will not cause any change in the state of the kernel.
If the kernel is then patched for SMP again, and numerous locks which were 'unlocked' by tasks running under the non-SMP kernel are actually still marked in memory as locked, would that not cause severe system instabilty or a deadlock condition?
Again, I only know the kernel by concept, and have never written a line of code for it. Excuse my ignorance. :)
(Log in to post comments)
SMP alternatives Posted Dec 15, 2005 14:05 UTC (Thu) by kpfleming (subscriber, #23250) [Link] You are confusing mutual exclusion/semaphore locks with 'bus' locks. There is no 'unlock' operation involved here; the 'lock' prefix instruction being referred to only affects the instruction it precedes, and there is an automatic 'unlock' of the bus when that instruction completes.
Switching from uni- to multi-processor mode won't even require holding all the kernel threads/processes in an idle state while this happens, it would just have to complete all the instruction patching before any threads could be allowed to run on the new CPU.
This is a very, very cool idea :-)
SMP alternatives Posted Dec 15, 2005 18:39 UTC (Thu) by Ross (subscriber, #4065) [Link] That's not how I read it.
"The main use of SMP alternatives in his patch is with spinlock operations; spinlocks can be patched in or edited out, as dictated by the configuration of the system at boot time."
It sounds like spinlocks will be turned into noops. This may be ok when going SMP->UP, but maybe not the other direction, and I wonder what kind of lock state would be retained when going SMP->UP->SMP...
SMP alternatives Posted Dec 15, 2005 18:59 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] To enable hotplug SMP -> UP -> SMP, you'd definitely need to retain spinlocks, or at least put a lightweight "take lock" instruction there as opposed to the full spin. Fully NOPping spinlocks out would be a disaster, as you note.
Elsewhere, though, you could nuke/replace LOCK prefixes as needed.
Safety Posted Dec 15, 2005 14:55 UTC (Thu) by corbet (editor, #1) [Link] Changing the functioning of spinlocks could certainly create trouble if parts of the kernel are certainly holding locks! By my reading of the patch, there are a couple of defenses against that problem, though:
SMP alternatives Posted Dec 25, 2005 19:46 UTC (Sun) by efexis (guest, #26355) [Link] Um, my guess is that you'd stop processes from running on the second processor -before- switching down to a single processor kernel. As only one processor could then even be holding locks, the locking mechanism becomes irrelevant, so can be NOOPed.
|
|||||||||||||