Prev: [PATCH 25/31] x86, lmb: Use lmb_memory_size()/lmb_free_memory_size() to get correct dma_reserve
Next: [PATCH 03/31] x86: Do not free zero sized per cpu areas
From: Lai Jiangshan on 28 Mar 2010 22:50 Even though in user mode or idle mode, rcu_check_callbacks() is not context switch, so we don't call rcu_preempt_note_context_switch() in rcu_check_callbacks(). Though there is no harm that calls rcu_preempt_note_context_switch() in rcu_check_callbacks(), but it is waste. rcu_check_callbacks() rcu_sched_qs() rcu_preempt_note_context_switch() Now, ->rcu_read_lock_nesting == 0, so we just calls rcu_preempt_qs(), but, rcu_preempt_check_callbacks() will call it again and set the ->rcu_read_unlock_special correct again. So let rcu_preempt_check_callbacks() handle things for us. Signed-off-by: Lai Jiangshan <laijs(a)cn.fujitsu.com> --- diff --git a/kernel/rcutree.c b/kernel/rcutree.c index 3ec8160..c7847ba 100644 --- a/kernel/rcutree.c +++ b/kernel/rcutree.c @@ -95,7 +95,7 @@ static int rcu_gp_in_progress(struct rcu_state *rsp) * how many quiescent states passed, just if there was at least * one since the start of the grace period, this just sets a flag. */ -void rcu_sched_qs(int cpu) +static void __rcu_sched_qs(int cpu) { struct rcu_data *rdp; @@ -103,6 +103,11 @@ void rcu_sched_qs(int cpu) rdp->passed_quiesc_completed = rdp->gpnum - 1; barrier(); rdp->passed_quiesc = 1; +} + +void rcu_sched_qs(int cpu) +{ + __rcu_sched_qs(cpu); rcu_preempt_note_context_switch(cpu); } @@ -1138,12 +1143,12 @@ void rcu_check_callbacks(int cpu, int user) * a quiescent state, so note it. * * No memory barrier is required here because both - * rcu_sched_qs() and rcu_bh_qs() reference only CPU-local + * __rcu_sched_qs() and rcu_bh_qs() reference only CPU-local * variables that other CPUs neither access nor modify, * at least not while the corresponding CPU is online. */ - rcu_sched_qs(cpu); + __rcu_sched_qs(cpu); rcu_bh_qs(cpu); } else if (!in_softirq()) { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |