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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, "Santos, Jose Renato G" <joserenato.santos@xxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Add RCU support into Xen - Repost
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 30 Jan 2007 20:37:21 +0000
Cc: "Turner, Yoshio" <yoshio_turner@xxxxxx>, Jose Renato Santos <jsantos@xxxxxxxxxx>, G John Janakiraman <john@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 30 Jan 2007 12:37:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C1E559AE.81B2%Keir.Fraser@xxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc5z5YIiS/CKex/Tb+azW+82olglwHqc/i/AMlxYuAAA1KFSgAAfs+1
Thread-topic: [Xen-devel] [PATCH] Add RCU support into Xen - Repost
User-agent: Microsoft-Entourage/11.3.3.061214
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().

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