Messages in this thread | | | Date | Tue, 22 Oct 2002 23:38:53 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH] NMI request/release |
| |
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 ?
Thanks Dipankar - 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/
| |