From: Ingo Molnar <mingo@elte.hu>
To: Cyrill Gorcunov <gorcunov@openvz.org>
Cc: Don Zickus <dzickus@redhat.com>,
"Huang, Ying" <ying.huang@intel.com>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip 2/2 resend] x86, traps: Drop nmi_reason_lock until it is really needed
Date: Wed, 2 Mar 2011 16:46:45 +0100 [thread overview]
Message-ID: <20110302154645.GA11827@elte.hu> (raw)
In-Reply-To: <4D6E631B.6040701@openvz.org>
* Cyrill Gorcunov <gorcunov@openvz.org> wrote:
> At moment we have only BSP apic configured to listen
> for external NMIs. So there is no reason for additional
> spinlock since only BSP will receive them.
>
> Though we still have UV chips which do enable external NMIs
> on all cpus, but since an approach to allow retrieving
> NMI reason on BSP only was working pretty fine before --
> I assume it still remains valid.
I'm not sure I get the point here: we might get NMIs on non-BSP on UV
systems ... so we want to remove the spinlock?
If UV systems can get NMIs on any CPU then the lock is needed.
It might have worked before - but UV systems are rare and relatively
new - plus the race window is small, so it might not have been triggered
in practice.
> Also it's worth to mention that an initial idea of all this
> NMI code-path changes was to make BSP hot-unpluggable but
> until all other parts of kernel is prepared for it (which
> might consume quite a time to implement) I believe we should
> not lock/unlock for nothing.
That would be another argument in favor of keeping the lock, right?
Thanks,
Ingo
next prev parent reply other threads:[~2011-03-02 15:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-02 15:32 [PATCH -tip 2/2 resend] x86, traps: Drop nmi_reason_lock until it is really needed Cyrill Gorcunov
2011-03-02 15:46 ` Ingo Molnar [this message]
2011-03-02 15:55 ` Cyrill Gorcunov
2011-03-02 16:03 ` Ingo Molnar
2011-03-02 16:13 ` Cyrill Gorcunov
2011-03-02 18:40 ` Don Zickus
2011-03-02 19:14 ` Cyrill Gorcunov
2011-03-02 19:46 ` Don Zickus
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=20110302154645.GA11827@elte.hu \
--to=mingo@elte.hu \
--cc=dzickus@redhat.com \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ying.huang@intel.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