Re: [PATCH] NMI request/release, version 4

Corey Minyard (cminyard@mvista.com)
Thu, 24 Oct 2002 08:08:22 -0500


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/