All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: linux-kernel@vger.kernel.org,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Manfred Spraul <manfred@colorfullife.com>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 2/3] rcu: don't set ->next_pending in rcu_start_batch()
Date: Tue, 10 Jan 2006 20:33:56 -0800	[thread overview]
Message-ID: <20060111043356.GL18252@us.ibm.com> (raw)
In-Reply-To: <43C3BAC2.C1F20B95@tv-sign.ru>

On Tue, Jan 10, 2006 at 04:46:42PM +0300, Oleg Nesterov wrote:
> I think it is better to set ->next_pending in the caller, when
> it is needed. This saves one parameter, and this coincides with
> cpu_quiet() beahaviour, which sets ->completed = ->cur itself.

Looks good to me, passes a one-hour torture test on x86.

						Thanx, Paul

Acked-by: Paul E. McKenney <paulmck@us.ibm.com>
> Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
> 
> --- 2.6.15/kernel/rcupdate.c~2_NPEND	2006-01-10 18:35:45.000000000 +0300
> +++ 2.6.15/kernel/rcupdate.c	2006-01-10 18:39:08.000000000 +0300
> @@ -249,12 +249,8 @@ static void rcu_do_batch(struct rcu_data
>   * active batch and the batch to be registered has not already occurred.
>   * Caller must hold rcu_state.lock.
>   */
> -static void rcu_start_batch(struct rcu_ctrlblk *rcp, struct rcu_state *rsp,
> -				int next_pending)
> +static void rcu_start_batch(struct rcu_ctrlblk *rcp, struct rcu_state *rsp)
>  {
> -	if (next_pending)
> -		rcp->next_pending = 1;
> -
>  	if (rcp->next_pending &&
>  			rcp->completed == rcp->cur) {
>  		rcp->next_pending = 0;
> @@ -288,7 +284,7 @@ static void cpu_quiet(int cpu, struct rc
>  	if (cpus_empty(rsp->cpumask)) {
>  		/* batch completed ! */
>  		rcp->completed = rcp->cur;
> -		rcu_start_batch(rcp, rsp, 0);
> +		rcu_start_batch(rcp, rsp);
>  	}
>  }
>  
> @@ -423,7 +419,8 @@ static void __rcu_process_callbacks(stru
>  		if (!rcp->next_pending) {
>  			/* and start it/schedule start if it's a new batch */
>  			spin_lock(&rsp->lock);
> -			rcu_start_batch(rcp, rsp, 1);
> +			rcp->next_pending = 1;
> +			rcu_start_batch(rcp, rsp);
>  			spin_unlock(&rsp->lock);
>  		}
>  	} else {
> 

      reply	other threads:[~2006-01-11  4:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-10 13:46 [PATCH 2/3] rcu: don't set ->next_pending in rcu_start_batch() Oleg Nesterov
2006-01-11  4:33 ` Paul E. McKenney [this message]

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=20060111043356.GL18252@us.ibm.com \
    --to=paulmck@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=oleg@tv-sign.ru \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.