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

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

> -----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
> 
> 
> 

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