From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
"fweisbec@gmail.com" <fweisbec@gmail.com>
Subject: Re: ia64 won't boot because of rcu_sched self-detected stall
Date: Fri, 24 Aug 2012 13:37:15 -0700 [thread overview]
Message-ID: <20120824203714.GT2472@linux.vnet.ibm.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19397175@ORSMSX104.amr.corp.intel.com>
On Thu, Aug 23, 2012 at 07:54:37PM +0000, Luck, Tony wrote:
> > Without the calls to rcu_idle_enter() and rcu_idle_exit(), RCU has no
> > way of knowing that the CPU is idle, so waits forever for a context
> > switch.
>
> Adding the calls at the places you suggested solves the problem. Thanks.
>
> Which tree is feeding these changes to linux-next? How do I get
> this ia64 fix into that tree so it will go to Linus in the same merge
> that the changes that required this will be in?
>
> Do you want me to create a patch (I can do that, but I'm not sure
> that I can write a good commit message). If someone else does,
> then it can be marked:
>
> Tested-by: Tony Luck <tony.luck@intel.com>
Does the following match what you tested? I optimistically assumed
that it was, but figured I should check. ;-)
Thanx, Paul
------------------------------------------------------------------------
ia64: Add missing RCU idle APIs on idle loop
Traditionally, the entire idle task served as an RCU quiescent state.
But when RCU read side critical sections started appearing within the
idle loop, this traditional strategy became untenable. The fix was to
create new RCU APIs named rcu_idle_enter() and rcu_idle_exit(), which
must be called by each architecture's idle loop so that RCU can tell
when it is safe to ignore a given idle CPU.
Unfortunately, this fix was never applied to ia64, a shortcoming remedied
by this commit.
Reported by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested by: Tony Luck <tony.luck@intel.com>
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index dd6fc14..3e316ec 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -29,6 +29,7 @@
#include <linux/kdebug.h>
#include <linux/utsname.h>
#include <linux/tracehook.h>
+#include <linux/rcupdate.h>
#include <asm/cpu.h>
#include <asm/delay.h>
@@ -279,6 +280,7 @@ cpu_idle (void)
/* endless idle loop with no priority at all */
while (1) {
+ rcu_idle_enter();
if (can_do_pal_halt) {
current_thread_info()->status &= ~TS_POLLING;
/*
@@ -309,6 +311,7 @@ cpu_idle (void)
normal_xtp();
#endif
}
+ rcu_idle_exit();
schedule_preempt_disabled();
check_pgt_cache();
if (cpu_is_offline(cpu))
next prev parent reply other threads:[~2012-08-24 20:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-21 22:45 ia64 won't boot because of rcu_sched self-detected stall Tony Luck
2012-08-21 23:20 ` Paul E. McKenney
2012-08-21 23:53 ` Luck, Tony
2012-08-22 0:46 ` Paul E. McKenney
2012-08-22 13:42 ` Luck, Tony
2012-08-22 15:12 ` Frederic Weisbecker
2012-08-22 15:29 ` Paul E. McKenney
2012-08-23 19:54 ` Luck, Tony
2012-08-24 20:37 ` Paul E. McKenney [this message]
2012-08-24 21:44 ` Luck, Tony
2012-08-24 22:06 ` Paul E. McKenney
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=20120824203714.GT2472@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-next@vger.kernel.org \
--cc=tony.luck@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;
as well as URLs for NNTP newsgroup(s).