All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Ying <ying.huang@intel.com>
To: Robert Richter <robert.richter@amd.com>
Cc: Don Zickus <dzickus@redhat.com>, "mingo@elte.hu" <mingo@elte.hu>,
	"andi@firstfloor.org" <andi@firstfloor.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>
Subject: Re: [PATCH 4/5] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU
Date: Thu, 21 Oct 2010 08:46:35 +0800	[thread overview]
Message-ID: <1287621995.19320.14.camel@yhuang-dev> (raw)
In-Reply-To: <20101020100316.GX5969@erda.amd.com>

On Wed, 2010-10-20 at 18:03 +0800, Robert Richter wrote:
> > > > > What about using raw_spin_trylock() instead? We don't have to wait
> > > > > here since we are already processing it by another cpu.
> > > > 
> > > > This would avoid a global lock and also deadlocking in case of a
> > > > potential #gp in the nmi handler.
> > > 
> > > I would feel more comfortable with it too.  I can't find a reason where
> > > trylock would do harm.
> > 
> > One possible issue can be as follow:
> > 
> > - PCI SERR NMI raised on CPU 0
> > - IOCHK NMI raised on CPU 1
> > 
> > If we use try lock, we may get unknown NMI on one CPU. Do you guys think
> > so?
> 
> This could be a valid point. On the other side the former
> implementation to let only handle cpu #0 i/o interrupts didn't trigger
> unknown nmis, so try_lock wouldn't change much compared to this.

Because we want to support BSP hot-remove, these NMIs may be redirected
to other CPUs. I think it may be possible after we hot-remove the BSP
PCI SERR NMI is routed to CPU 1, while IOCHK NMI is routed to CPU 2. The
raw_spin_lock() here is for that.

Best Regards,
Huang Ying


  reply	other threads:[~2010-10-21  0:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-16  2:22 [PATCH 0/5] x86, NMI: give NMI handler a face-lift Don Zickus
2010-10-16  2:22 ` [PATCH 1/5] x86, NMI: Add NMI symbol constants and rename memory parity to PCI SERR Don Zickus
2010-10-16 16:36   ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-16  2:22 ` [PATCH 2/5] x86, NMI: Add touch_nmi_watchdog to io_check_error delay Don Zickus
2010-10-16 16:36   ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-16  2:22 ` [PATCH 3/5] x86, NMI: Rewrite NMI handler Don Zickus
2010-10-16 16:36   ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-16 17:29     ` Peter Zijlstra
2010-10-16 18:20       ` Ingo Molnar
2010-10-16 18:40         ` Anca Emanuel
2010-10-17  0:46       ` Don Zickus
2010-10-17 10:42         ` Peter Zijlstra
2010-10-18  3:06           ` Huang Ying
2010-10-18  8:24             ` Peter Zijlstra
2010-10-16  2:22 ` [PATCH 4/5] x86, NMI: Allow NMI reason io port (0x61) to be processed on any CPU Don Zickus
2010-10-16 16:37   ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-19 15:07   ` [PATCH 4/5] " Robert Richter
2010-10-19 16:25     ` Robert Richter
2010-10-19 18:37       ` Don Zickus
2010-10-20  0:23         ` Huang Ying
2010-10-20 10:03           ` Robert Richter
2010-10-21  0:46             ` Huang Ying [this message]
2010-10-20 14:27           ` Don Zickus
2010-10-21  0:40             ` Huang Ying
2010-10-21  1:18               ` Don Zickus
2010-10-21  1:25                 ` Huang Ying
2010-10-21  2:37                   ` Don Zickus
2010-10-21  2:53                     ` Huang Ying
2010-10-16  2:22 ` [PATCH 5/5] x86, NMI: Remove do_nmi_callback logic Don Zickus
2010-10-16 16:37   ` [tip:perf/core] " tip-bot for Huang Ying
2010-10-19 15:03   ` [PATCH 5/5] " Robert Richter
2010-10-19 16:01     ` Don Zickus
2010-10-19 16:23       ` Robert Richter
2010-10-19 15:01 ` [PATCH 0/5] x86, NMI: give NMI handler a face-lift Robert Richter

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=1287621995.19320.14.camel@yhuang-dev \
    --to=ying.huang@intel.com \
    --cc=andi@firstfloor.org \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=robert.richter@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.