WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Add RCU support into Xen - Repost
From: "Santos, Jose Renato G" <joserenato.santos@xxxxxx>
Date: Wed, 31 Jan 2007 17:52:58 -0600
Cc: "Turner, Yoshio" <yoshio_turner@xxxxxx>, Jose Renato Santos <jsantos@xxxxxxxxxx>, G John Janakiraman <john@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 31 Jan 2007 15:52:49 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <08CA2245AFCF444DB3AC415E47CC40AF6D4803@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C1E559AE.81B2%Keir.Fraser@xxxxxxxxxxxx> <C1E55D01.81B7%Keir.Fraser@xxxxxxxxxxxx> <08CA2245AFCF444DB3AC415E47CC40AF6D4803@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc5z5YIiS/CKex/Tb+azW+82olglwHqc/i/AMlxYuAAA1KFSgAAfs+1AAP4hbAABinNAA==
Thread-topic: [Xen-devel] [PATCH] Add RCU support into Xen - Repost
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
<Prev in Thread] Current Thread [Next in Thread>