Messages in this thread | | | Date | Fri, 15 Nov 2002 03:18:22 -0500 (EST) | From | Zwane Mwaikambo <> | Subject | Re: NMI handling rework for x86 |
| |
On Fri, 15 Nov 2002, Dipankar Sarma wrote:
> Once you remove a handler from the list, any subsequent NMI is *not* > going to see the handler. So even if another CPU is executing the same > handler, if you wait for the RCU callback, you can guarantee that > no-one is executing the deleted handler. RCU will wait for all the > CPUs to context switch or execute user-level code atleast once.
I think you're confusing NMI handling, they aren't like your normal interrupts. You're not going to see that context switch.
> That meant any other CPU which might have been executing the NMI > handler at the time of deletion has now exited from the handler. > > > I don't think you can rely on completion() to ensure this. Its hardly an > > Corey's code doesn't rely on completion() to ensure this, it relies > on RCU to make sure that nobody is running the handler. The key is > that once the pointers between the prev and the next of the deleted
Can you change prev and next atomically?
> NMI handler are set, subsequent NMIs aren't going to see that handler. > context switch/user-level means that CPU must have exited any > NMI handler it may have been executing at the time of deletion.
Again, are you mistaking this for a normal interrupt?
> > atomic operation in this context, whats wrong with spin_trylock(nmi_handler_lock) > > and do an early bailout on failure? > > spin_trylock modifies the lock cacheline, so cacheline bouncing.
At a fair interrupt rate i'd rather have that fill my caches, less time spent in the NMI handler means more overall system time.
Zwane -- function.linuxpower.ca
- 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/
| |