RE: [Xen-devel] [PATCH] Add RCU support into Xen - Repost

["Santos, Jose Renato G" <joserenato.santos@xxxxxx>]

Keir

The attached patch changes all accesses to domain_list and domain_hash
to use RCU.
I have also included a patch restoring the definition of rcu_read_lock()
and rcu_read_unlock() back to rcupdate.h, since these are used on the
patch. I think you have agreed to have those back according to your last
email.
These patches apply cleanly to c/s 13703.

Thanks

Renato


> -----Original Message-----
> From: Santos, Jose Renato G 
> Sent: Tuesday, January 30, 2007 2:46 PM
> To: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Turner, Yoshio; Jose Renato Santos; G John Janakiraman
> Subject: RE: [Xen-devel] [PATCH] Add RCU support into Xen - Repost
> 
>  
> 
> > -----Original Message-----
> > From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> > Sent: Tuesday, January 30, 2007 12:37 PM
> > To: Keir Fraser; Santos, Jose Renato G; 
> xen-devel@xxxxxxxxxxxxxxxxxxx
> > Cc: Turner, Yoshio; Jose Renato Santos; G John Janakiraman
> > Subject: Re: [Xen-devel] [PATCH] Add RCU support into Xen - Repost
> > 
> > On 30/1/07 8:23 pm, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:
> > 
> > > This would require some interaction with new
> > find_domain_by_id(). The
> > > invocation of find_domain_by_id() and all subsequent uses of its 
> > > return value will need to be contained within an
> > > rcu_read_lock()/rcu_read_unlock() pair which seems kind 
> of a pain. 
> > > Particularly since this documentation is weak -- it may not 
> > > immediately be clear in future what is being protected by
> > the rcu read-side region (since the lock routines do not take a 
> > parameter).
> > > And I'm not sure how the documentation helps: who will it
> > be useful to?
> > 
> > Thinking about this a little more, we could wrap up the 
> > rcu_read_[un]lock invocations into a more informative API in this 
> > case:
> > get_domain_by_id_rcu(d) and put_domain_rcu(d), analagous with 
> > get_domain/put_domain. get_domain_by_rcu(d) would include 
> an implicit 
> > rcu_read_lock(), and put_domain_rcu(d) an implicit 
> rcu_read_unlock().
> > 
> 
>   That is a good idea, although I would prefer if we could 
> find better names for the rcu functions. Get/put may give the 
> wrong impression that a reference counter is being 
> incremented/decremented which would not be the case. It could 
> also give the wrong impression that the matching "put" could 
> be invoked any time later which may leave us with an invalid 
> domain pointer (if the pointer is kept beyond the current Xen 
> invocation). What about "find_domain_rcu()"/"end_find_domain_rcu()" ? 
> 
> Renato
> 
> 
> 
> > I could certainly live with that, and then keep direct use of
> > rcu_read_lock()/rcu_read_unlock() for small critical 
> regions (e.g., in 
> > the implementation of get_domain_by_id()).
> > 
> >  -- Keir
> > 
> > > Linux needs them for more than just documentation as it has
> > to disable
> > > preemption (a feature which I don't expect Xen to ever 
> acquire). I 
> > > don't know whether it would have them otherwise.
> > > 
> > >  -- Keir
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> > 
> > 
> > 
>

Attachment: domain_list_rcu.patch
Description: domain_list_rcu.patch

Attachment: define_rcu_read.patch
Description: define_rcu_read.patch

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