[Xen-devel] Re: rcu support in xen

["Mike D. Day" <ncmike@xxxxxxxxxx>]

On 25/03/07 09:28 +0100, Keir Fraser wrote:
> On 24/3/07 19:22, "Mike D. Day" <ncmike@xxxxxxxxxx> wrote:
>
> > Due to recent conversion of get_domain_by_id to use rcu techniques I
> > looked at the file xen/include/xen/rcupdate.h and noticed
> > rcu_read_lock is defined as:
> >
> > define rcu_read_lock(x)       do { } while (0)
> >
> > as well as the corresponding unlock and other related macros.
> >
> > Apologies if this has already been answered, but when will the real
> > rcu code get into -unstable?
> The whole point of RCU is that read-side critical sections have no (or very
> little) synchronisation overhead. In Xen the rcu_read_[un]lock functions are
> only present to make the code clearer and to seome extent self documenting.
> On Linux they also disable involuntary preemption during the critical
> section (which is not needed on Xen, of course).
>
> So, in short, Xen already has a complete RCU implementation.
I see, the thing that threw me off was the sparse checker code in the
linux rcu_read_lock() implementation, as a comparison. However, it
doesn't do anything either.

By the way, the linux implementation does not require a dummy lock
object:


#define rcu_read_lock() \
        do { \
                preempt_disable(); \
                __acquire(RCU); \
        } while(0)


This is better - in my opinion, it makes it clearer that the rcu reader
is not actually synchronizing on a spinlock. 

I'd be happy to submit a patch for the reader lock/unlock macros.

Mike

--
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@xxxxxxxxxx AIM: ncmikeday  Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel