Messages in this thread | | | Date | Sat, 14 May 2005 01:50:59 +0530 | From | Dipankar Sarma <> | Subject | Re: [Lse-tech] Re: [PATCH] cpusets+hotplug+preepmt broken |
| |
On Fri, May 13, 2005 at 12:59:53PM -0700, Paul Jackson wrote: > Srivatsa, replying to Dinakar: > > This in fact was the reason that we added lock_cpu_hotplug > > in sched_setaffinity. > > We do need to be clear about how these locks work, their semantics, what > they require and what they insure, and their various interactions. > > This is not easy stuff to get right. > > I notice that the documentation for lock_cpu_hotplug() is a tad on > the skimpy side: > > /* Stop CPUs going up and down. */ > > That's it, so far as I can see. Interaction of hotplug locking with > the rest of the kernel has been, is now, and will continue to be, a > difficult area. More care than this needs to be put into explaining > the use, semantics and interactions of any locking involved. > > In particular, in my view, locks should guard data. What data does > lock_cpu_hotplug() guard? I propose that it guards cpu_online_map. > > I recommend considering a different name for this lock. Perhaps > 'cpu_online_sem', instead of 'cpucontrol'? And perhaps the > lock_cpu_hotplug() should be renamed, to say 'lock_cpu_online'?
No. CPU hotplug uses two different locking - see both lock_cpu_hotplug() and __stop_machine_run(). Anyone reading cpu_online_map with preemption disabled is safe from cpu hotplug even without taking any lock.
Thanks Dipankar - 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/
| |