lkml.org 
[lkml]   [2002]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.728 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site