On Fri, May 02, 2008 at 02:59:29PM +0200, Peter Zijlstra wrote: > On Fri, 2008-05-02 at 05:42 -0700, Paul E. McKenney wrote: > > > And here is one scenario that makes me doubt that my imagination is > > faulty: > > > > 1. CPU 0 disables irqs. > > > > 2. CPU 1 disables irqs. > > > > 3. CPU 0 invokes smp_call_function(). But CPU 1 will never respond > > because its irqs are disabled. > > > > 4. CPU 1 invokes smp_call_function(). But CPU 0 will never respond > > because its irqs are disabled. > > > > Looks like inherent deadlock to me, requiring that smp_call_function() > > be invoked with irqs enabled. > > > > So, what am I missing here? > > The wish to do it anyway ;-) > > I can imagine some situations where I'd like to try anyway and fall back > to a slower path when failing. > > With the initial design we would simply allocate data, stick it on the > queue and call the ipi (when needed). > > This is perfectly deadlock free when wait=0 and it just returns -ENOMEM > on allocation failure. Yeah, I'm just talking about the wait=0 case. (btw. I'd rather the core API takes some data rather than allocates some itself, eg because you might want to have it on the stack). For the wait=1 case, something very clever such as processing pending requests in a polling loop might be cool... however I'd rather not add such complexity until someone needs it (you could stick a comment in there outlining your algorithm). But I'd just rather not have peole rely on it yet. > It it doesn't return -ENOMEM I know its been queued and will be > processed at some point, if it does fail, I can deal with it in another > way. At least with IPIs I think we can guarantee they will be processed on the target after we queue them. > I know I'd like to do that and I suspect Nick has a few use cases up his > sleeve as well. It would be handy. The "quickly kick something off on another CPU" is pretty nice in mm/ when you have per-cpu queues or caches that might want to be flushed. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
