Messages in this thread |  | | Date | Thu, 24 Oct 2002 08:08:22 -0500 | | From | Corey Minyard <> | | Subject | Re: [PATCH] NMI request/release, version 4 |
| |
Dipankar Sarma wrote:
>On Wed, Oct 23, 2002 at 04:53:34PM -0500, Corey Minyard wrote: > > >>>After local_irq_count() went away, the idle CPU check was broken >>>and that meant that if you had an idle CPU, it could hold up RCU >>>grace period completion. >>> >>Ah, much better. That seems to fix it. >> >> >Great! Do you have any latency numbers ? Just curious. > Unfortunately not. 3 seconds is well within the realm of human observation with printk.
>>>It might just be simpler to use completions instead - >>> >>> call_rcu(&(handler->rcu), free_nmi_handler, handler); >>> init_completion(&handler->completion); >>> spin_unlock_irqrestore(&nmi_handler_lock, flags); >>> wait_for_completion(&handler->completion); >>> >>>and do >>> >>> complete(&handler->completion); >>> >>>in the the RCU callback. >>> >>> >>> >>I was working under the assumption that the spinlocks were needed. But >>now I see that there are spinlocks in wait_for_completion. You did get >>init_completion() and call_rcu() backwards, they would need to be the >>opposite order, I think. >> >> > >AFAICS, the ordering of call_rcu() and init_completion should not matter >because the CPU that is executing them would not have gone >through a quiescent state and thus the RCU callback cannot happen. >Only after a context swtich in wait_for_completion(), the callback >is possible. > Yes, I think you are right. I'm still not used to the RCUs :-).
-Corey
- 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/
|  |