public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mathieu Desnoyers <compudj@krystal.dyndns.org>
Cc: ltt-dev@lists.casi.polymtl.ca, linux-kernel@vger.kernel.org
Subject: Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)
Date: Sun, 8 Feb 2009 19:47:48 -0800	[thread overview]
Message-ID: <20090209034748.GP7120@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090209010825.GA23462@Krystal>

On Sun, Feb 08, 2009 at 08:08:25PM -0500, Mathieu Desnoyers wrote:
> * Mathieu Desnoyers (compudj@krystal.dyndns.org) wrote:
> > * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > > On Sun, Feb 08, 2009 at 02:36:06PM -0800, Paul E. McKenney wrote:
> > > > On Sun, Feb 08, 2009 at 04:46:10PM -0500, Mathieu Desnoyers wrote:
> > > 
> > > [ . . . ]
> > > 
> > > > > I ran your modified version within my benchmarks :
> > > > > 
> > > > > with return value : 14.164 cycles per read
> > > > > without return value : 16.4017 cycles per read
> > > > > 
> > > > > So we have a 14% performance decrease due to this. We also pollute the
> > > > > branch prediction buffer and we add a cache access due to the added
> > > > > variables in the TLS. Returning the value has the clear advantage of
> > > > > letting the compiler keep it around in registers or on the stack, which
> > > > > clearly costs less.
> > > > > 
> > > > > So I think the speed factor outweights the visual considerations. Maybe
> > > > > we could switch to something like :
> > > > > 
> > > > > unsigned int qparity;
> > > > > 
> > > > > urcu_read_lock(&qparity);
> > > > > ...
> > > > > urcu_read_unlock(&qparity);
> > > > > 
> > > > > That would be a bit like local_irq_save() in the kernel, except that we
> > > > > could do it in a static inline because we pass the address. I
> > > > > personnally dislike the local_irq_save() way of hiding the fact that it
> > > > > writes to the variable in a "clever" macro. I'd really prefer to leave
> > > > > the " & ".
> > > > > 
> > > > > What is your opinion ?
> > > > 
> > > > My current opinion is that I can avoid the overflow problem and the
> > > > need to recheck, which might get rid of the need for both arguments
> > > > and return values while still maintaining good performance.  The trick
> > > > is to use only the topmost bit for the grace-period counter, and all
> > > > the rest of the bits for nesting.  That way, no matter what value of
> > > > global counter one picks up, it will be waited for (since there are but
> > > > two values that the global counter takes on).
> > > > 
> > > > But just now coding it, so will see if it actually works.
> > > 
> > > Seems to work, and seems to be pretty fast on my machine, anyway.
> > > This one adapts itself to 32- and 64-bit machines, though almost
> > > all of the code is common.  It does do a check, but avoids array
> > > indexing, arguments, and return values.
> > > 
> > > How does it do on your hardware?
> > > 
> > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > 
> > Wow...
> > 
> > Patch updated against HEAD.
> > 
> > Time per read : 7.53622 cycles
> > 
> > Half of what we had previously.. I'll have to look at the assembly. :)
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> > ---
> > 
> >  test_urcu.c        |    6 +++---
> >  test_urcu_timing.c |    6 +++---
> >  urcu.c             |   23 ++++++++++-------------
> >  urcu.h             |   42 +++++++++++++++++++++++++++++-------------
> >  4 files changed, 45 insertions(+), 32 deletions(-)
> > 
> > diff --git a/test_urcu.c b/test_urcu.c
> > index f6be45b..f115a4a 100644
> > --- a/test_urcu.c
> > +++ b/test_urcu.c
> > @@ -72,7 +72,7 @@ void rcu_copy_mutex_unlock(void)
> >  
> >  void *thr_reader(void *arg)
> >  {
> > -	int qparity, i, j;
> > +	int i, j;
> >  	struct test_array *local_ptr;
> >  
> >  	printf("thread %s, thread id : %lx, tid %lu\n",
> > @@ -83,14 +83,14 @@ void *thr_reader(void *arg)
> >  
> >  	for (i = 0; i < 100000; i++) {
> >  		for (j = 0; j < 100000000; j++) {
> > -			rcu_read_lock(&qparity);
> > +			rcu_read_lock();
> >  			local_ptr = rcu_dereference(test_rcu_pointer);
> >  			if (local_ptr) {
> >  				assert(local_ptr->a == 8);
> >  				assert(local_ptr->b == 12);
> >  				assert(local_ptr->c[55] == 2);
> >  			}
> > -			rcu_read_unlock(&qparity);
> > +			rcu_read_unlock();
> >  		}
> >  	}
> >  
> > diff --git a/test_urcu_timing.c b/test_urcu_timing.c
> > index 57fda4f..9903705 100644
> > --- a/test_urcu_timing.c
> > +++ b/test_urcu_timing.c
> > @@ -94,7 +94,7 @@ static cycles_t reader_time[NR_READ] __attribute__((aligned(128)));
> >  
> >  void *thr_reader(void *arg)
> >  {
> > -	int qparity, i, j;
> > +	int i, j;
> >  	struct test_array *local_ptr;
> >  	cycles_t time1, time2;
> >  
> > @@ -107,12 +107,12 @@ void *thr_reader(void *arg)
> >  	time1 = get_cycles();
> >  	for (i = 0; i < OUTER_READ_LOOP; i++) {
> >  		for (j = 0; j < INNER_READ_LOOP; j++) {
> > -			rcu_read_lock(&qparity);
> > +			rcu_read_lock();
> >  			local_ptr = rcu_dereference(test_rcu_pointer);
> >  			if (local_ptr) {
> >  				assert(local_ptr->a == 8);
> >  			}
> > -			rcu_read_unlock(&qparity);
> > +			rcu_read_unlock();
> >  		}
> >  	}
> >  	time2 = get_cycles();
> > diff --git a/urcu.c b/urcu.c
> > index 08fb75d..2914b66 100644
> > --- a/urcu.c
> > +++ b/urcu.c
> > @@ -19,17 +19,17 @@
> >  
> >  pthread_mutex_t urcu_mutex = PTHREAD_MUTEX_INITIALIZER;
> >  
> > -/* Global quiescent period parity */
> > -int urcu_qparity;
> > +/* Global grace period counter */
> > +long urcu_gp_ctr;
> >  
> > -int __thread urcu_active_readers[2];
> > +long __thread urcu_active_readers;
> >  
> >  /* Thread IDs of registered readers */
> >  #define INIT_NUM_THREADS 4
> >  
> >  struct reader_data {
> >  	pthread_t tid;
> > -	int *urcu_active_readers;
> > +	long *urcu_active_readers;
> >  };
> >  
> >  static struct reader_data *reader_data;
> > @@ -60,11 +60,9 @@ void internal_urcu_unlock(void)
> >  /*
> >   * called with urcu_mutex held.
> >   */
> > -static int switch_next_urcu_qparity(void)
> > +static void switch_next_urcu_qparity(void)
> >  {
> > -	int old_parity = urcu_qparity;
> > -	urcu_qparity = 1 - old_parity;
> > -	return old_parity;
> > +	urcu_gp_ctr += RCU_GP_CTR_BOTTOM_BIT;
> >  }
> >  
> >  static void force_mb_all_threads(void)
> > @@ -89,7 +87,7 @@ static void force_mb_all_threads(void)
> >  	mb();	/* read sig_done before ending the barrier */
> >  }
> >  
> > -void wait_for_quiescent_state(int parity)
> > +void wait_for_quiescent_state(void)
> >  {
> >  	struct reader_data *index;
> >  
> > @@ -101,7 +99,7 @@ void wait_for_quiescent_state(int parity)
> >  		/*
> >  		 * BUSY-LOOP.
> >  		 */
> > -		while (index->urcu_active_readers[parity] != 0)
> > +		while (rcu_old_gp_ongoing(index->urcu_active_readers))
> >  			barrier();
> >  	}
> >  	/*
> > @@ -115,17 +113,16 @@ void wait_for_quiescent_state(int parity)
> >  
> >  static void switch_qparity(void)
> >  {
> > -	int prev_parity;
> >  
> >  	/* All threads should read qparity before accessing data structure. */
> >  	/* Write ptr before changing the qparity */
> >  	force_mb_all_threads();
> > -	prev_parity = switch_next_urcu_qparity();
> > +	switch_next_urcu_qparity();
> >  
> >  	/*
> >  	 * Wait for previous parity to be empty of readers.
> >  	 */
> > -	wait_for_quiescent_state(prev_parity);
> > +	wait_for_quiescent_state();
> >  }
> >  
> >  void synchronize_rcu(void)
> > diff --git a/urcu.h b/urcu.h
> > index b6b5c7b..e83c69f 100644
> > --- a/urcu.h
> > +++ b/urcu.h
> > @@ -66,23 +66,39 @@ static inline void atomic_inc(int *v)
> >  
> >  #define SIGURCU SIGUSR1
> >  
> > -/* Global quiescent period parity */
> > -extern int urcu_qparity;
> > +#define RCU_GP_CTR_BOTTOM_BIT (sizeof(long) == 4 ? 0x80000000 : 0x100L)
> 
> Shouldn't it be the opposite ?
> 
> e.g.
> 
> #define RCU_GP_CTR_BOTTOM_BIT (sizeof(long) == 4 ? 0x100L : 0x80000000L)

Absolutely not!!!  For 32-bit systems, the GP count is only the upper
bit.  That is exactly what allows the overflow check to be omitted.
For 64-bit systems, I rely on the upper 56 bits taking a couple of
millenia to overflow.

For 64-bit systems, one could also use only the upper bit
(0x8000000000000000), and that might actually make for better code.

> > +#define RCU_GP_CTR_NEST_MASK (RCU_GP_CTR_BOTTOM_BIT - 1)
> >  
> > -extern int __thread urcu_active_readers[2];
> > +/* Global quiescent period counter with low-order bits unused. */
> > +extern long urcu_gp_ctr;
> >  
> > -static inline int get_urcu_qparity(void)
> > +extern long __thread urcu_active_readers;
> > +
> > +static inline int rcu_old_gp_ongoing(long *value)
> >  {
> > -	return urcu_qparity;
> > +	long v;
> > +
> > +	if (value == NULL)
> > +		return 0;
> > +	v = ACCESS_ONCE(*value);
> > +	if (sizeof(long) == 4) {
> > +		return (v & RCU_GP_CTR_NEST_MASK) &&
> > +		       ((v ^ ACCESS_ONCE(urcu_gp_ctr)) & ~RCU_GP_CTR_NEST_MASK);
> 
> There must be something about the ^ I am missing ? Compared to it, the
> 64-bits test is a - , with < 0...

Yep.  For 32 bits, if the top bit is the same as that of the current value
of the counter, we must wait.  I could have written:

	       (v & ~RCU_GP_CTR_NEST_MASK) !=
	       (ACCESS_ONCE(urcu_gp_ctr) & ~RCU_GP_CTR_NEST_MASK)

but doing so would require two "&" operations.  Though perhaps the
compiler would have figured it out...

							Thanx, Paul

> Mathieu
> 
> > +	} else {
> > +		return (v & RCU_GP_CTR_NEST_MASK) &&
> > +		       (v - ACCESS_ONCE(urcu_gp_ctr) < 0);
> > +	}
> >  }
> >  
> > -/*
> > - * urcu_parity should be declared on the caller's stack.
> > - */
> > -static inline void rcu_read_lock(int *urcu_parity)
> > +static inline void rcu_read_lock(void)
> >  {
> > -	*urcu_parity = get_urcu_qparity();
> > -	urcu_active_readers[*urcu_parity]++;
> > +	long tmp;
> > +
> > +	tmp = urcu_active_readers;
> > +	if ((tmp & RCU_GP_CTR_NEST_MASK) == 0)
> > +		urcu_active_readers = urcu_gp_ctr + 1;
> > +	else
> > +		urcu_active_readers = tmp + 1;
> >  	/*
> >  	 * Increment active readers count before accessing the pointer.
> >  	 * See force_mb_all_threads().
> > @@ -90,14 +106,14 @@ static inline void rcu_read_lock(int *urcu_parity)
> >  	barrier();
> >  }
> >  
> > -static inline void rcu_read_unlock(int *urcu_parity)
> > +static inline void rcu_read_unlock(void)
> >  {
> >  	barrier();
> >  	/*
> >  	 * Finish using rcu before decrementing the pointer.
> >  	 * See force_mb_all_threads().
> >  	 */
> > -	urcu_active_readers[*urcu_parity]--;
> > +	urcu_active_readers--;
> >  }
> >  
> >  extern void *urcu_publish_content(void **ptr, void *new);
> > 
> > 
> > 
> > -- 
> > Mathieu Desnoyers
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > 
> > _______________________________________________
> > ltt-dev mailing list
> > ltt-dev@lists.casi.polymtl.ca
> > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2009-02-09  3:47 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06  3:05 [RFC git tree] Userspace RCU (urcu) for Linux Mathieu Desnoyers
2009-02-06  4:58 ` [RFC git tree] Userspace RCU (urcu) for Linux (repost) Mathieu Desnoyers
2009-02-06 13:06   ` Paul E. McKenney
2009-02-06 16:34     ` Paul E. McKenney
2009-02-07 15:10       ` Paul E. McKenney
2009-02-07 22:16         ` Paul E. McKenney
2009-02-08  0:19           ` Mathieu Desnoyers
2009-02-07 23:38         ` Mathieu Desnoyers
2009-02-08  0:44           ` Paul E. McKenney
2009-02-08 21:46             ` Mathieu Desnoyers
2009-02-08 22:36               ` Paul E. McKenney
2009-02-09  0:24                 ` Paul E. McKenney
2009-02-09  0:54                   ` Mathieu Desnoyers
2009-02-09  1:08                     ` [ltt-dev] " Mathieu Desnoyers
2009-02-09  3:47                       ` Paul E. McKenney [this message]
2009-02-09  3:42                     ` Paul E. McKenney
2009-02-09  0:40                 ` [ltt-dev] " Mathieu Desnoyers
2009-02-08 22:44       ` Mathieu Desnoyers
2009-02-09  4:11         ` Paul E. McKenney
2009-02-09  4:53           ` Mathieu Desnoyers
2009-02-09  5:17             ` [ltt-dev] " Mathieu Desnoyers
2009-02-09  7:03               ` Mathieu Desnoyers
2009-02-09 15:33                 ` Paul E. McKenney
2009-02-10 19:17                   ` Mathieu Desnoyers
2009-02-10 21:16                     ` Paul E. McKenney
2009-02-10 21:28                       ` Mathieu Desnoyers
2009-02-10 22:21                         ` Paul E. McKenney
2009-02-10 22:58                           ` Paul E. McKenney
2009-02-10 23:01                             ` Paul E. McKenney
2009-02-11  0:57                           ` Mathieu Desnoyers
2009-02-11  5:28                             ` Paul E. McKenney
2009-02-11  6:35                               ` Mathieu Desnoyers
2009-02-11 15:32                                 ` Paul E. McKenney
2009-02-11 18:52                                   ` Mathieu Desnoyers
2009-02-11 20:09                                     ` Paul E. McKenney
2009-02-11 21:42                                       ` Mathieu Desnoyers
2009-02-11 22:08                                         ` Mathieu Desnoyers
     [not found]                                         ` <20090212003549.GU6694@linux.vnet.ibm.com>
2009-02-12  2:33                                           ` Paul E. McKenney
2009-02-12  2:37                                             ` Paul E. McKenney
2009-02-12  4:10                                               ` Mathieu Desnoyers
2009-02-12  5:09                                                 ` Paul E. McKenney
2009-02-12  5:47                                                   ` Mathieu Desnoyers
2009-02-12 16:18                                                     ` Paul E. McKenney
2009-02-12 18:40                                                       ` Mathieu Desnoyers
2009-02-12 20:28                                                         ` Paul E. McKenney
2009-02-12 21:27                                                           ` Mathieu Desnoyers
2009-02-12 23:26                                                             ` Paul E. McKenney
2009-02-13 13:12                                                               ` Mathieu Desnoyers
2009-02-12  4:08                                             ` Mathieu Desnoyers
2009-02-12  5:01                                               ` Paul E. McKenney
2009-02-12  7:05                                                 ` Mathieu Desnoyers
2009-02-12 16:46                                                   ` Paul E. McKenney
2009-02-12 19:29                                                     ` Mathieu Desnoyers
2009-02-12 20:02                                                       ` Paul E. McKenney
2009-02-12 20:09                                                         ` Mathieu Desnoyers
2009-02-12 20:35                                                           ` Paul E. McKenney
2009-02-12 21:15                                                             ` Mathieu Desnoyers
2009-02-12 20:13                                                         ` Linus Torvalds
2009-02-12 20:39                                                           ` Paul E. McKenney
2009-02-12 21:15                                                             ` Linus Torvalds
2009-02-12 21:59                                                               ` Paul E. McKenney
2009-02-13 13:50                                                                 ` Nick Piggin
2009-02-13 14:56                                                                   ` Paul E. McKenney
2009-02-13 15:10                                                                     ` Mathieu Desnoyers
2009-02-13 15:55                                                                       ` Mathieu Desnoyers
2009-02-13 16:18                                                                         ` Linus Torvalds
2009-02-13 17:33                                                                           ` Mathieu Desnoyers
2009-02-13 17:53                                                                             ` Linus Torvalds
2009-02-13 18:09                                                                               ` Linus Torvalds
2009-02-13 18:54                                                                                 ` Mathieu Desnoyers
2009-02-13 19:36                                                                                   ` Paul E. McKenney
2009-02-14  5:07                                                                                     ` Mike Frysinger
2009-02-14  5:20                                                                                       ` Paul E. McKenney
2009-02-14  5:46                                                                                         ` Mike Frysinger
2009-02-14 15:06                                                                                           ` Paul E. McKenney
2009-02-14 17:37                                                                                             ` Mike Frysinger
2009-02-22 14:23                                                                                           ` Pavel Machek
2009-02-22 18:28                                                                                             ` Mike Frysinger
2009-02-14  6:42                                                                                         ` Mathieu Desnoyers
2009-02-14  3:15                                                                                 ` [Uclinux-dist-devel] " Mike Frysinger
2009-02-13 18:40                                                                               ` Mathieu Desnoyers
2009-02-13 16:05                                                                   ` Linus Torvalds
2009-02-14  3:11                                                                     ` [Uclinux-dist-devel] " Mike Frysinger
2009-02-14  4:58                                                           ` Robin Getz
2009-02-12 19:38                                                     ` Mathieu Desnoyers
2009-02-12 20:17                                                       ` Paul E. McKenney
2009-02-12 21:53                                                         ` Mathieu Desnoyers
2009-02-12 23:04                                                           ` Paul E. McKenney
2009-02-13 12:49                                                             ` Mathieu Desnoyers
2009-02-11  5:08                     ` Lai Jiangshan
2009-02-11  8:58                       ` Mathieu Desnoyers
2009-02-09 13:23               ` Paul E. McKenney
2009-02-09 17:28                 ` Mathieu Desnoyers
2009-02-09 17:47                   ` Paul E. McKenney
2009-02-09 18:13                     ` Mathieu Desnoyers
2009-02-09 18:19                       ` Mathieu Desnoyers
2009-02-09 18:37                       ` Paul E. McKenney
2009-02-09 18:49                         ` Paul E. McKenney
2009-02-09 19:05                           ` Mathieu Desnoyers
2009-02-09 19:15                             ` Mathieu Desnoyers
2009-02-09 19:35                               ` Paul E. McKenney
2009-02-09 19:23                             ` Paul E. McKenney
2009-02-09 13:16             ` Paul E. McKenney
2009-02-09 17:19               ` Bert Wesarg
2009-02-09 17:34                 ` Paul E. McKenney
2009-02-09 17:35                   ` Bert Wesarg
2009-02-09 17:40                     ` Paul E. McKenney
2009-02-09 17:42                       ` Mathieu Desnoyers
2009-02-09 18:00                         ` Paul E. McKenney
2009-02-09 17:45                       ` Bert Wesarg
2009-02-09 17:59                         ` Paul E. McKenney
2009-02-07 22:56   ` Kyle Moffett
2009-02-07 23:50     ` Mathieu Desnoyers
2009-02-08  0:13     ` Paul E. McKenney
2009-02-06  8:55 ` [RFC git tree] Userspace RCU (urcu) for Linux Bert Wesarg
2009-02-06 11:36   ` 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=20090209034748.GP7120@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=compudj@krystal.dyndns.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@lists.casi.polymtl.ca \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox