Dipankar Sarma wrote:
>On Tue, Oct 22, 2002 at 01:05:57PM -0500, Corey Minyard wrote:
>
>
>>>You need to walk the list in call_nmi_handlers from nmi interrupt handler where
>>>preemption is not an issue anyway. Using RCU you can possibly do a safe
>>>walking of the nmi handlers. To do this, your update side code
>>>(request/release nmi) will still have to be serialized (spinlock), but
>>>you should not need to wait for completion of any other CPU executing
>>>the nmi handler, instead provide wrappers for nmi_handler
>>>allocation/free and there free the nmi_handler using an RCU callback
>>>(call_rcu()). The nmi_handler will not be freed until all the CPUs
>>>have done a contex switch or executed user-level or been idle.
>>>This will gurantee that *this* nmi_handler is not in execution
>>>and can safely be freed.
>>>
>>>This of course is a very simplistic view of the things, there could
>>>be complications that I may have overlooked. But I would be happy
>>>to help out on this if you want.
>>>
>>>
>>>
>>This doesn't sound any simpler than what I am doing right now. In fact,
>>it sounds more complex. Am I correct? What I am doing is pretty simple
>>and correct. Maybe more complexity would be required if you couldn't
>>atomically update a pointer, but I think simplicity should win here.
>>
>>
>
>I would vote for simplicity and would normally agree with you here. But
>it seems to me that using RCU, you can avoid atmic operations
>and cache line bouncing of calling_nmi_handlers in the fast path
>(nmi interrupt handler). One could argue whether it is really
>a fast path or not, but if you are using it for profiling, I would
>say it is. No ?
>
I would vote against using it for profiling; profiling has it's own
special fast-path, anyway. The NMI watchdog only gets hit once every
minute or so, it seems, so that seems suitable for this.
I've looked at the RCU code a little more, and I think I understand it
better. I think your scenario will work, if it's true that it won't be
called until all CPUs have done what you say. I'll look at it a little
more.
-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/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:59 EST