Messages in this thread | | | Date | Mon, 9 Feb 2009 09:47:41 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [ltt-dev] [RFC git tree] Userspace RCU (urcu) for Linux (repost) |
| |
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.)
> > 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.
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
| |