Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost)

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Mon, Feb 09, 2009 at 01:13:41PM -0500, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > On Mon, Feb 09, 2009 at 12:28:17PM -0500, Mathieu Desnoyers wrote:
> > > * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > > > On Mon, Feb 09, 2009 at 12:17:37AM -0500, Mathieu Desnoyers wrote:
> > 
> > [ . . . ]
> > 
> > > > > The new version is pushed into the repository. I changed you patch a
> > > > > bit. Flaming is welcome. :)
> > > > 
> > > > Looks reasonable at first glance.  Just out of curiosity, why are
> > > > urcu_gp_ctr and urcu_active_readers int rather than char?  I guess that
> > > > one reason would be that many architectures work better with int than
> > > > with char...
> > > 
> > > Exactly. This is done to make sure we don't end up having false register
> > > dependencies causing stalls on such architectures. I'll add a comment.
> > 
> > Are there any 64-bit architectures that would prefer a long to an int?
> > (Other than really old Alpha CPUs, that is.)
> 
> None that I am aware of, but Christoph or Peter would probably know more
> than I do on this aspect.
> 
> > > > So, how many cycles did this save?  ;-)
> > > 
> > > On x86_64, it's pretty much the same as before. It just helps having the
> > > 32 and 64 bits algorithms being exactly the same, which I think is a
> > > very good thing.
> > 
> > Good point!
> > 
> > > BTW, my tests were done without any CMOV instruction due to the standard
> > > gcc options I used. Given think past discussion about CMOV :
> > > 
> > > http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus
> > > 
> > > It does not seem like such a good idea to use it anyway, given it can
> > > take 10 cycles to run on a P4a
> > 
> > Fair enough!
> > 
> > > BTW, do you think having the 256 nested rcu read locks limitation could
> > > become a problem ? I really think an application has recursion problem
> > > if it does, but this is not impossible, especially on a particularly
> > > badly designed tree-traversal algorithm on a 64-bits arch...
> > 
> > I don't know of any code in the Linux kernel that nests rcu_read_lock()
> > anywhere near that deep.  And if someone does find such a case, it is
> > pretty easy to use 15 bits rather than 8 to hold the nesting depth, just
> > by changing the definition of RCU_GP_CTR_BIT.
> > 
> 
> You know what ? Changing RCU_GP_CTR_BIT to 16 uses a
> testw %ax, %ax instead of a testb %al, %al. The trick here is that
> RCU_GP_CTR_BIT must be a multiple of 8 so we can use a full 8-bits,
> 16-bits or 32-bits bitmask for the lower order bits.
> 
> On 64-bits, using a RCU_GP_CTR_BIT of 32 is also ok. It uses a testl.
> 
> To provide 32-bits compability and allow the deepest nesting possible, I
> think it makes sense to use
> 
> /* Use the amount of bits equal to half of the architecture long size */
> #define RCU_GP_CTR_BIT (sizeof(long) << 2)

You lost me on this one:

	sizeof(long) << 2 = 0x10

I could believe the following (run on a 32-bit machine):

	1 << (sizeof(long) * 8 - 1) = 0x80000000

Or, if you were wanting to use a bit halfway up the word, perhaps this:

	1 << (sizeof(long) * 4 - 1) = 0x8000

Or am I confused?

							Thanx, Paul

> Mathieu
> 
> 
> > 							Thanx, Paul
> > 
> > > Mathieu
> > > 
> > > > 						Thanx, Paul
> > > > 
> > > > > Mathieu
> > > > > 
> > > > > > Mathieu
> > > > > > 
> > > > > > > > > Again, looks interesting!  Looks plausible, although I have not 100%
> > > > > > > > > convinced myself that it is perfectly bug-free.  But I do maintain
> > > > > > > > > a healthy skepticism of purported RCU algorithms, especially ones that
> > > > > > > > > I have written.  ;-)
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > That's always good. I also tend to always be very skeptical about what I
> > > > > > > > write and review.
> > > > > > > > 
> > > > > > > > Thanks for the thorough review.
> > > > > > > 
> > > > > > > No problem -- it has been quite fun!  ;-)
> > > > > > > 
> > > > > > > 							Thanx, Paul
> > > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > 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
> > > > 
> > > 
> > > -- 
> > > Mathieu Desnoyers
> > > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
> > 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68