[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140718000413.GF8690@linux.vnet.ibm.com>
Date: Thu, 17 Jul 2014 17:04:13 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Sasha Levin <sasha.levin@...cle.com>
Cc: bobby.prani@...il.com, linux-kernel@...r.kernel.org,
mingo@...nel.org, laijs@...fujitsu.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
peterz@...radead.org, rostedt@...dmis.org, dhowells@...hat.com,
edumazet@...gle.com, dvhart@...ux.intel.com, fweisbec@...il.com,
oleg@...hat.com, sbw@....edu, linux-rt-users@...r.kernel.org
Subject: Re: [PATCH RFC tip/core/rcu 1/2] rcu: Rationalize kthread spawning
On Thu, Jul 17, 2014 at 12:02:05PM -0400, Sasha Levin wrote:
> On 07/17/2014 01:33 AM, Paul E. McKenney wrote:
> > On Wed, Jul 16, 2014 at 10:57:39PM -0400, Sasha Levin wrote:
> >> On 07/14/2014 06:06 AM, Paul E. McKenney wrote:
> >>> From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
> >>>
> >>> Currently, RCU spawns kthreads from several different early_initcall()
> >>> functions. Although this has served RCU well for quite some time,
> >>> as more kthreads are added a more deterministic approach is required.
> >>> This commit therefore causes all of RCU's early-boot kthreads to be
> >>> spawned from a single early_initcall() function.
> >>>
> >>> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> >>
> >> Hey Paul,
> >>
> >> I've updated to today's -next and my VM started hanging on boot. Bisect
> >> pointed out this patch.
> >>
> >> I don't have any further info right now, but can provide whatever you'll
> >> find useful.
> >
> > Could you please add initcall_debug to qemu's -append list? If sysrq-T
> > works that early, its output would be helpful as well.
> >
> > Your .config would also be helpful.
>
> Hi Pranith, Paul,
>
> I've attached my boot log with initcall_debug, as well as the .config.
Hello, Sasha,
Looks like you might have run into the same thing that Ingo ran into.
Could you please try the following patch? (Or wait for it to show up
in the next -next, if you prefer.)
Thanx, Paul
------------------------------------------------------------------------
rcu: Allow for NULL tick_nohz_full_mask when nohz_full= missing
If there isn't a nohz_full= kernel parameter specified, then
tick_nohz_full_mask can legitimately be NULL. This can cause
problems when RCU's boot code tries to cpumask_or() this value into
rcu_nocb_mask. In addition, if NO_HZ_FULL_ALL=y, there is no point
in doing the cpumask_or() in the first place because this will cause
RCU_NOCB_CPU_ALL=y, which in turn will have all bits already set in
rcu_nocb_mask.
This commit therefore avoids the cpumask_or() if NO_HZ_FULL_ALL=y
and checks for !tick_nohz_full_running otherwise, this latter check
catching cases when there was no nohz_full= kernel parameter specified.
Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index f62b7f2f6abd..00dc411e9676 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2479,9 +2479,10 @@ static void __init rcu_spawn_nocb_kthreads(struct rcu_state *rsp)
if (rcu_nocb_mask == NULL)
return;
-#ifdef CONFIG_NO_HZ_FULL
- cpumask_or(rcu_nocb_mask, rcu_nocb_mask, tick_nohz_full_mask);
-#endif /* #ifdef CONFIG_NO_HZ_FULL */
+#if defined(CONFIG_NO_HZ_FULL) && !defined(CONFIG_NO_HZ_FULL_ALL)
+ if (tick_nohz_full_running)
+ cpumask_or(rcu_nocb_mask, rcu_nocb_mask, tick_nohz_full_mask);
+#endif /* #if defined(CONFIG_NO_HZ_FULL) && !defined(CONFIG_NO_HZ_FULL_ALL) */
if (ls == -1) {
ls = int_sqrt(nr_cpu_ids);
rcu_nocb_leader_stride = ls;
--
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