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

Open Source and information security mailing list archives

Message-ID: <20090209181341.GA15514@Krystal>
Date:	Mon, 9 Feb 2009 13:13:41 -0500
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Christoph Hellwig <hch@...radead.org>
Cc:	ltt-dev@...ts.casi.polymtl.ca, linux-kernel@...r.kernel.org
Subject: Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux
	(repost)

* Paul E. McKenney (paulmck@...ux.vnet.ibm.com) wrote:
> On Mon, Feb 09, 2009 at 12:28:17PM -0500, Mathieu Desnoyers wrote:
> > * Paul E. McKenney (paulmck@...ux.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)

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@...ts.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives