From: Ingo Molnar <mingo@kernel.org>
To: Don Zickus <dzickus@redhat.com>
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 19:35:01 +0200 [thread overview]
Message-ID: <20140508173501.GA9838@gmail.com> (raw)
In-Reply-To: <20140508163333.GZ39568@redhat.com>
* Don Zickus <dzickus@redhat.com> wrote:
> > > 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.
But the polling would only happen if there's NMI traffic, so that's
fine. So as long as polling stops some time after the last PMI use,
it's a good solution.
This would also address a lot of NMI handling related fragility.
Thanks,
Ingo
next prev parent reply other threads:[~2014-05-08 17:35 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
2014-05-08 17:35 ` Ingo Molnar [this message]
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=20140508173501.GA9838@gmail.com \
--to=mingo@kernel.org \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=dzickus@redhat.com \
--cc=fweisbec@gmail.com \
--cc=gong.chen@linux.intel.com \
--cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).