From: Dipankar Sarma <dipankar@in.ibm.com>
To: Zwane Mwaikambo <zwane@holomorphy.com>
Cc: Corey Minyard <cminyard@mvista.com>,
Linus Torvalds <torvalds@transmeta.com>,
"Heater, Daniel (IndSys, GEFanuc,
VMIC)" <Daniel.Heater@gefanuc.com>,
John Levon <levon@movementarian.org>,
linux-kernel@vger.kernel.org
Subject: Re: NMI handling rework for x86
Date: Fri, 15 Nov 2002 14:20:31 +0530 [thread overview]
Message-ID: <20021115142031.D5088@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0211150307240.2750-100000@montezuma.mastecende.com>; from zwane@holomorphy.com on Fri, Nov 15, 2002 at 03:18:22AM -0500
On Fri, Nov 15, 2002 at 03:18:22AM -0500, Zwane Mwaikambo wrote:
> 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.
Let us examine the race -
CPU #0 CPU #1 CPU #2
(free_nmi P) execute NMI P syscall
delete from list
call_rcu NMI (doesn't see P)
wait for completion process in kernel process in kernel
(context switch)
context switch context switch
----------- RCU complete NMI handler P must be complete here --------------
RCU handler tasklet
callback: complete()
nmi freeing task
wakes up and proceeds.
> > 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?
You don't have to, the traversal during __list_for_each_rcu() is done
in only one direction. So writing out the next pointer is sufficiently
atomic for subsequent NMIs not to see the deleted handler. Either you
see the deleted handler or you don't.
> > 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.
It isn't going to fill your caches, it is going to bounce around from
CPU to CPU on every NMI since every NMI will modify the cache line.
So you hurt performance.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
next prev parent reply other threads:[~2002-11-15 8:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-15 4:30 NMI handling rework for x86 Corey Minyard
2002-11-15 4:40 ` Zwane Mwaikambo
2002-11-15 6:10 ` Dipankar Sarma
2002-11-15 7:40 ` Zwane Mwaikambo
2002-11-15 8:13 ` Dipankar Sarma
2002-11-15 8:18 ` Zwane Mwaikambo
2002-11-15 8:50 ` Dipankar Sarma [this message]
2002-11-15 17:41 ` John Levon
2002-11-15 22:46 ` Zwane Mwaikambo
2002-11-15 5:12 ` John Levon
2002-11-15 5:19 ` John Levon
2002-11-15 14:13 ` Corey Minyard
2002-11-15 17:48 ` John Levon
2002-11-15 19:00 ` Corey Minyard
2002-11-15 19:28 ` John Levon
2002-11-15 19:35 ` Corey Minyard
2002-11-17 2:00 ` John Levon
2002-11-17 2:31 ` Zwane Mwaikambo
2002-11-18 16:48 ` Corey Minyard
2002-11-18 15:34 ` Corey Minyard
2002-11-15 5:20 ` Randy.Dunlap
2002-11-15 9:50 ` Mikael Pettersson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021115142031.D5088@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=Daniel.Heater@gefanuc.com \
--cc=cminyard@mvista.com \
--cc=levon@movementarian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=zwane@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox