From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Don Zickus <dzickus@redhat.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 1/2] nohz: Disable LOCKUP_DETECTOR when NO_HZ_FULL is enabled
Date: Thu, 16 May 2013 13:06:02 -0700 [thread overview]
Message-ID: <20130516200602.GF4442@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130516175602.GL19669@dyad.programming.kicks-ass.net>
On Thu, May 16, 2013 at 07:56:02PM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 08:07:06AM -0700, Paul E. McKenney wrote:
> > On Thu, May 16, 2013 at 10:10:27AM +0200, Peter Zijlstra wrote:
> > > On Wed, May 15, 2013 at 01:04:01PM -0400, Steven Rostedt wrote:
> > > > On Wed, 2013-05-15 at 18:59 +0200, Peter Zijlstra wrote:
> > > >
> > > > > At which point we could run the watchdog without perf_event_task_tick().
> > > >
> > > > At which point we can drop the disable LOCKUP_DETECTOR when NO_HZ_FULL
> > > > is enabled ;-)
> > > >
> > >
> > > Can we? The thing I'm worried about is RCU (of course!). ISTR we rely on RCU
> > > working in NMI context. AFAIR for RCU to work, we need to come out of out magic
> > > NO_HZ state since that would've put RCU into EQS.
> > >
> > > Frederic, PaulMck?
> >
> > Not sure I understand the question, but hopefully the verbiage below helps.
> >
> > Only RCU read-side critical sections need to work in NMI context,
> > and RCU hooks into nmi_enter() and nmi_exit() to handle this, and this
> > will work in NO_HZ_FULL in the same way that it works for NO_HZ_IDLE.
> >
> > But if there are no NMIs, RCU doesn't care. In other words, RCU needs
> > to know about NMIs so that it can deal with any RCU read-side critical
> > sections in the NMI handlers, but RCU doesn't rely on NMIs happening at
> > any particular time or frequency.
>
> I suppose the fundamental question was: will receiving NMIs negate NO_HZ_FULL's
> functionality? That is, will the getting of NMIs make us drop out of NO_HZ_FULL
> and re-enable all sorts of things?
>
> Because clearly RCU needs to exit from EQS, which might (or might not) mean
> leaving NO_HZ_FULL.
>
> I'm not entirely up-to-date on those details.
My belief is that NMIs won't cause NO_HZ_FULL to kick that CPU out of
adaptive-ticks mode, but I must defer to Frederic on that.
Of course, the NMI -will- cause OS jitter on whichever CPU handles it,
which some people would want to avoid.
Thanx, Paul
next prev parent reply other threads:[~2013-05-17 7:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-14 16:02 [GIT PULL] Nohz fixes Frederic Weisbecker
2013-05-14 16:02 ` [PATCH 1/2] nohz: Disable LOCKUP_DETECTOR when NO_HZ_FULL is enabled Frederic Weisbecker
2013-05-15 8:37 ` Peter Zijlstra
2013-05-15 15:06 ` Don Zickus
2013-05-15 15:27 ` Steven Rostedt
2013-05-15 16:26 ` Don Zickus
2013-05-15 16:59 ` Peter Zijlstra
2013-05-15 17:04 ` Steven Rostedt
2013-05-16 8:10 ` Peter Zijlstra
2013-05-16 11:38 ` Frederic Weisbecker
2013-05-16 17:57 ` Peter Zijlstra
2013-05-16 15:07 ` Paul E. McKenney
2013-05-16 17:56 ` Peter Zijlstra
2013-05-16 18:32 ` Steven Rostedt
2013-05-16 23:14 ` Frederic Weisbecker
2013-05-19 16:18 ` Paul E. McKenney
2013-05-16 20:06 ` Paul E. McKenney [this message]
2013-05-15 17:11 ` Peter Zijlstra
2013-05-15 17:50 ` Don Zickus
2013-05-15 16:55 ` Peter Zijlstra
2013-05-15 15:59 ` Frederic Weisbecker
2013-05-14 16:02 ` [PATCH 2/2] nohz: Warn if the machine can not perform nohz_full Frederic Weisbecker
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=20130516200602.GF4442@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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