From: Don Zickus <dzickus@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: x86@kernel.org, "Peter Zijlstra" <peterz@infradead.org>,
ak@linux.intel.com, gong.chen@linux.intel.com,
LKML <linux-kernel@vger.kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
andi@firstfloor.org
Subject: Re: [PATCH 1/5] x86, nmi: Add new nmi type 'external'
Date: Thu, 8 May 2014 12:33:33 -0400 [thread overview]
Message-ID: <20140508163333.GZ39568@redhat.com> (raw)
In-Reply-To: <20140507162746.GA15779@gmail.com>
On Wed, May 07, 2014 at 06:27:46PM +0200, Ingo Molnar wrote:
> > [...] But I guess in theory, if a PMI NMI comes in and before the
> > cpu can accept it and GHES NMI comes in, then it would suffice to
> > say it may get dropped. That would be not be good. Though the race
> > would be very small.
> >
> > I don't have a good idea how to handle that.
>
> Well, are GHES NMIs reasserted if they are not handled? I don't know
> but there's a definite answer to that hardware behavior question.
I can't find anything that explicitly says the NMI will be re-asserted, so
I will it does not. Andi, do you know? (I am not sure who maintains GHES
any more).
>
> > On the flip side, we have the same exact problem, today, with the
> > other common external NMIs (SERR, IO). If a PCI SERR comes in at
> > the same time as a PMI, then it gets dropped. Worse, it doesn't get
> > re-enabled and blocks future SERRs (just found this out two weeks
> > ago because of a dirty perf status register on boot).
> >
> > Again, I don't have a solution to juggle between PMI performance and
> > reliable delivery. We could do away with the spinlocks and go back
> > to single cpu delivery (like it used to be). Then devise a
> > mechanism to switch delivery to another cpu upon hotplug.
> >
> > Thoughts?
>
> I'd say we should do a delayed timer that makes sure that all possible
> handlers are polled after an NMI is triggered, but never at a high
> rate.
Hmm, I was thinking about it and wanted to avoid a poll as I hear
complaints here and there about the nmi_watchdog constantly wasting power
cycles with its polling.
I was wondering if I could do a status read outside the spinlock, then if
a bit is set, just grab the spin_lock and re-read the status. But then
looking at the GHES code, I am not sure if it is as easy to read the
status bit as it is for a PCI_SERR/IO_CHK NMI.
Andi thoughts here? Should I poke Tony Luck?
Otherwise I can set up the polling if that doesn't work.
Cheers,
Don
next prev parent reply other threads:[~2014-05-08 16:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 15:34 [PATCH 0/5 RESEND] x86, nmi: Various fixes and cleanups Don Zickus
2014-05-07 15:34 ` [PATCH 1/5] x86, nmi: Add new nmi type 'external' Don Zickus
2014-05-07 15:38 ` Ingo Molnar
2014-05-07 16:02 ` Don Zickus
2014-05-07 16:27 ` Ingo Molnar
2014-05-07 16:48 ` Don Zickus
2014-05-08 16:33 ` Don Zickus [this message]
2014-05-08 17:35 ` Ingo Molnar
2014-05-08 17:52 ` Don Zickus
2014-05-09 7:10 ` Ingo Molnar
2014-05-09 13:36 ` Don Zickus
2014-05-07 15:34 ` [PATCH 2/5] x86, nmi: Add boot line option 'panic_on_unrecovered_nmi' and 'panic_on_io_nmi' Don Zickus
2014-05-07 15:34 ` [PATCH 3/5] x86, nmi: Remove 'reason' value from unknown nmi output Don Zickus
2014-05-07 15:34 ` [PATCH 4/5] x86, nmi: Move default external NMI handler to its own routine Don Zickus
2014-05-07 15:34 ` [PATCH 5/5] x86, nmi: Add better NMI stats to /proc/interrupts and show handlers Don Zickus
2014-05-07 15:42 ` Ingo Molnar
2014-05-07 16:04 ` Don Zickus
2014-05-07 16:30 ` Ingo Molnar
2014-05-07 19:50 ` Elliott, Robert (Server Storage)
2014-05-08 1:28 ` Don Zickus
2014-05-08 6:04 ` Ingo Molnar
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=20140508163333.GZ39568@redhat.com \
--to=dzickus@redhat.com \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=fweisbec@gmail.com \
--cc=gong.chen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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
Powered by JetHome