All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	netdev@vger.kernel.org, davem@davemloft.net, kaber@trash.net,
	torvalds@linux-foundation.org, shemminger@vyatta.com,
	dada1@cosmosbay.com, jeff.chua.linux@gmail.com, paulus@samba.org,
	mingo@elte.hu, laijs@cn.fujitsu.com, jengelh@medozas.de,
	r000n@r000n.net, benh@kernel.crashing.org
Subject: Re: [RFC PATCH] v3 RCU implementation with fast grace periods
Date: Tue, 21 Apr 2009 09:51:51 -0700	[thread overview]
Message-ID: <20090421165151.GJ6642@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090421151034.GA3792@Krystal>

On Tue, Apr 21, 2009 at 11:10:35AM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:

[ . . . ]

> > +void synchronize_rcu_fgp(void)
> > +{
> > +	mutex_lock(&rcu_fgp_mutex);
> > +	
> > +	/* CPUs must see earlier change before parity flip. */
> > +	smp_call_function(rcu_fgp_do_mb, NULL, 1);
> > +
> 
> Hrm, my original comment about missing smp_mb() here still applies, I
> don't think we have come to an agreement yet.

My argument is that smp_call_function() must necessarily contain a
full memory barrier, otherwise it cannot function properly.  ;-)

> > +	/*
> > +	 * We must flip twice to correctly handle tasks that stall
> > +	 * in rcu_read_lock_fgp() between the time that they fetch
> > +	 * rcu_fgp_ctr and the time that the store to their CPU's
> > +	 * rcu_fgp_active_readers.  No matter when they resume
> > +	 * execution, we will wait for them to get to the corresponding
> > +	 * rcu_read_unlock_fgp().
> > +	 */
> > +	ACCESS_ONCE(rcu_fgp_ctr) ^= RCU_FGP_PARITY;  /* flip parity 0 -> 1 */
> > +	rcu_fgp_wait_for_quiescent_state();	     /* wait for old readers */
> > +	ACCESS_ONCE(rcu_fgp_ctr) ^= RCU_FGP_PARITY;  /* flip parity 1 -> 0 */
> > +	rcu_fgp_wait_for_quiescent_state();	     /* wait for old readers */
> > +
> > +	/* Prevent CPUs from reordering out of prior RCU critical sections. */
> > +	smp_call_function(rcu_fgp_do_mb, NULL, 1);
> > +
> 
> Same here.
> 
> So we would need to either add a smp_mb() at both of these locations, or
> use on_each_cpu() rather than smp_call_function. Note that this is to
> ensure that the "updater" thread executes these memory barriers.

Or rely on the barriers that must be part of smp_call_function.  ;-)

						Thanx, Paul

> Mathieu
> 
> 
> > +	rcu_fgp_completed++;
> > +	mutex_unlock(&rcu_fgp_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(synchronize_rcu_fgp);
> > +
> > +/**
> > + * rcu_fgp_batches_completed - return batches completed.
> > + * @sp: srcu_struct on which to report batch completion.
> > + *
> > + * Report the number of batches, correlated with, but not necessarily
> > + * precisely the same as, the number of grace periods that have elapsed.
> > + */
> > +long rcu_fgp_batches_completed(void)
> > +{
> > +	return rcu_fgp_completed;
> > +}
> > +EXPORT_SYMBOL_GPL(rcu_fgp_batches_completed);
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2009-04-21 16:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21  4:59 [RFC PATCH] v3 RCU implementation with fast grace periods Paul E. McKenney
2009-04-21 15:10 ` Mathieu Desnoyers
2009-04-21 16:51   ` Paul E. McKenney [this message]
2009-04-21 21:11     ` Mathieu Desnoyers
2009-04-21 23:07       ` Paul E. McKenney
2009-04-22 15:49         ` Mathieu Desnoyers

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=20090421165151.GJ6642@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=jeff.chua.linux@gmail.com \
    --cc=jengelh@medozas.de \
    --cc=kaber@trash.net \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=r000n@r000n.net \
    --cc=shemminger@vyatta.com \
    --cc=torvalds@linux-foundation.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.