lkml.org 
[lkml]   [2009]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-02-09 18:51    [W:0.191 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site