[tip/core/rcu,20/23] rcu: Remove callback acceleration from grace-period initialization

Message ID 1346350718-30937-20-git-send-email-paulmck@linux.vnet.ibm.com
State New
Headers show

Commit Message

Paul E. McKenney Aug. 30, 2012, 6:18 p.m.
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>

Before grace-period initialization was moved to a kthread, the CPU
invoking this code would have at least one callback that needed
a grace period, often a newly registered callback.  However, moving
grace-period initialization means that the CPU with the callback
that was requesting a grace period is not necessarily the CPU that
is initializing the grace period, so this acceleration is less
valuable.  Because it also adds to the complexity of reasoning about
correctness, this commit removes it.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 kernel/rcutree.c |   19 -------------------
 1 files changed, 0 insertions(+), 19 deletions(-)

Comments

Josh Triplett Sept. 3, 2012, 9:42 a.m. | #1
On Thu, Aug 30, 2012 at 11:18:35AM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> 
> Before grace-period initialization was moved to a kthread, the CPU
> invoking this code would have at least one callback that needed
> a grace period, often a newly registered callback.  However, moving
> grace-period initialization means that the CPU with the callback
> that was requesting a grace period is not necessarily the CPU that
> is initializing the grace period, so this acceleration is less
> valuable.  Because it also adds to the complexity of reasoning about
> correctness, this commit removes it.
> 
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Reviewed-by: Josh Triplett <josh@joshtriplett.org>

>  kernel/rcutree.c |   19 -------------------
>  1 files changed, 0 insertions(+), 19 deletions(-)
> 
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index 86903df..44609c3 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -1055,25 +1055,6 @@ static int rcu_gp_init(struct rcu_state *rsp)
>  	rsp->gpnum++;
>  	trace_rcu_grace_period(rsp->name, rsp->gpnum, "start");
>  	record_gp_stall_check_time(rsp);
> -
> -	/*
> -	 * Because this CPU just now started the new grace period, we
> -	 * know that all of its callbacks will be covered by this upcoming
> -	 * grace period, even the ones that were registered arbitrarily
> -	 * recently.    Therefore, advance all RCU_NEXT_TAIL callbacks
> -	 * to RCU_NEXT_READY_TAIL.  When the CPU later recognizes the
> -	 * start of the new grace period, it will advance all callbacks
> -	 * one position, which will cause all of its current outstanding
> -	 * callbacks to be handled by the newly started grace period.
> -	 *
> -	 * Other CPUs cannot be sure exactly when the grace period started.
> -	 * Therefore, their recently registered callbacks must pass through
> -	 * an additional RCU_NEXT_READY stage, so that they will be handled
> -	 * by the next RCU grace period.
> -	 */
> -	rdp = __this_cpu_ptr(rsp->rda);
> -	rdp->nxttail[RCU_NEXT_READY_TAIL] = rdp->nxttail[RCU_NEXT_TAIL];
> -
>  	raw_spin_unlock_irqrestore(&rnp->lock, flags);
>  
>  	/* Exclude any concurrent CPU-hotplug operations. */
> -- 
> 1.7.8
>

Patch

diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index 86903df..44609c3 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1055,25 +1055,6 @@  static int rcu_gp_init(struct rcu_state *rsp)
 	rsp->gpnum++;
 	trace_rcu_grace_period(rsp->name, rsp->gpnum, "start");
 	record_gp_stall_check_time(rsp);
-
-	/*
-	 * Because this CPU just now started the new grace period, we
-	 * know that all of its callbacks will be covered by this upcoming
-	 * grace period, even the ones that were registered arbitrarily
-	 * recently.    Therefore, advance all RCU_NEXT_TAIL callbacks
-	 * to RCU_NEXT_READY_TAIL.  When the CPU later recognizes the
-	 * start of the new grace period, it will advance all callbacks
-	 * one position, which will cause all of its current outstanding
-	 * callbacks to be handled by the newly started grace period.
-	 *
-	 * Other CPUs cannot be sure exactly when the grace period started.
-	 * Therefore, their recently registered callbacks must pass through
-	 * an additional RCU_NEXT_READY stage, so that they will be handled
-	 * by the next RCU grace period.
-	 */
-	rdp = __this_cpu_ptr(rsp->rda);
-	rdp->nxttail[RCU_NEXT_READY_TAIL] = rdp->nxttail[RCU_NEXT_TAIL];
-
 	raw_spin_unlock_irqrestore(&rnp->lock, flags);
 
 	/* Exclude any concurrent CPU-hotplug operations. */