From dec0710b70ba69053aaf6d6a2cf66ca282ab2d9e Mon Sep 17 00:00:00 2001 From: Anson Huang Date: Tue, 27 Sep 2011 18:20:19 +0800 Subject: [PATCH] ENGR00156637 [MX6]Reboot take long time on SMP Add work around to the reboot issue of SMP, with SMP, all the CPUs need to do _rcu_barrier, if we enqueue an rcu callback, we need to make sure CPU tick to stay alive until we take care of those by completing the appropriate grace period. This work around only work when the reboot command issue, so it didn't impact normal kernel feature. Signed-off-by: Anson Huang --- kernel/rcutree.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/kernel/rcutree.c b/kernel/rcutree.c index ba06207b1dd3..3585b42eb7cb 100644 --- a/kernel/rcutree.c +++ b/kernel/rcutree.c @@ -50,6 +50,7 @@ #include #include #include +#include #include "rcutree.h" @@ -1480,6 +1481,7 @@ static void rcu_process_callbacks(struct softirq_action *unused) /* If we are last CPU on way to dyntick-idle mode, accelerate it. */ rcu_needs_cpu_flush(); } +static atomic_t rcu_barrier_cpu_count; /* * Wake up the current CPU's kthread. This replaces raise_softirq() @@ -1536,6 +1538,14 @@ __call_rcu(struct rcu_head *head, void (*func)(struct rcu_head *rcu), return; } + /* Work around for reboot issue, check rcu_barrier_cpu_count + to see whether it is in the _rcu_barrier process, do + tick_nohz_restart_sched_tick if yes. If we enqueue an rcu + callback, we need the CPU tick to stay alive until we take care + of those by completing the appropriate grace period. */ + if (atomic_read(&rcu_barrier_cpu_count) != 0) + tick_nohz_restart_sched_tick(); + /* * Force the grace period if too many callbacks or too long waiting. * Enforce hysteresis, and don't invoke force_quiescent_state() @@ -1750,7 +1760,6 @@ static int rcu_needs_cpu_quick_check(int cpu) } static DEFINE_PER_CPU(struct rcu_head, rcu_barrier_head) = {NULL}; -static atomic_t rcu_barrier_cpu_count; static DEFINE_MUTEX(rcu_barrier_mutex); static struct completion rcu_barrier_completion; -- 2.39.2