[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1368729178.6828.105.camel@gandalf.local.home>
Date: Thu, 16 May 2013 14:32:58 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Don Zickus <dzickus@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/2] nohz: Disable LOCKUP_DETECTOR when NO_HZ_FULL is
enabled
On Thu, 2013-05-16 at 19:56 +0200, Peter Zijlstra wrote:
> 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?
It shouldn't. The nmi_enter() notifies RCU that it can no longer ignore
this CPU, where as nmi_enter() tells it that it can ignore it, as it has
re-entered user space.
>
> Because clearly RCU needs to exit from EQS, which might (or might not) mean
> leaving NO_HZ_FULL.
Yep, but the two are pretty much agnostic from each other.
We only need to leave NO_HZ_FULL if RCU (or anything for that matter)
required having a tick again. But as Paul said, getting an NMI in idle
wont restart the tick, so there's no need to restart it here either.
Now if an NMI were to do a call_rcu() then it would require a tick. But
NMIs doing call_rcu() has much bigger issues to worry about ;-)
-- Steve
>
> I'm not entirely up-to-date on those details.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists