Messages in this thread | | | Date | Sun, 27 Aug 2006 18:57:44 +1000 | From | Nick Piggin <> | Subject | Re: [RFC][PATCH 0/4] Redesign cpu_hotplug locking. |
| |
Andrew Morton wrote: > On Sun, 27 Aug 2006 12:41:16 +0530 > Dipankar Sarma <dipankar@in.ibm.com> wrote:
>>Is this too difficult for people to follow ? > > > Apparently. What's happening is that lock_cpu_hotplug() is seen as some > amazing thing which will prevent an *event* from occurring.
It prevents the event from occurring as much as a lock taken in the prepare notifier does, right? Or am I misunderstanding something?
> > There's an old saying "lock data, not code". What data is being locked > here? It's the subsystem's per-cpu resources which we want to lock. We > shouldn't consider the lock as being some way of preventing an event from > happening.
I agree. Where possible these things should be very simple either with the per-cpu macros, or using local locking (versus one's notifier).
I think there can be some valid use of the hotplug lock when working with cpumasks rather than individual CPUs (or if you simply want to prevent a cpu from going down while programming hardware) and having a new lock and new notifier is too heavyweight. Or do we want to move away from the hotplug lock completely?
Hmm, so I don't know if I like the idea of a reentrant rwmutex for the hotplug lock so it can be sprinkled everywhere... call it a refcount or not it smells slightly BKLish (looks easy but it could be a nightmare to audit).
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |