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] Rendezvous selected cpus

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Rendezvous selected cpus
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 04 Feb 2008 07:30:45 +0000
Delivery-date: Sun, 03 Feb 2008 23:30:37 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D8F47@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achlcy9d/rIcXbNERJmDq57BBZNC3QBGTqlDAA+IkJAADVOV/A==
Thread-topic: [Xen-devel] [PATCH] Rendezvous selected cpus
User-agent: Microsoft-Entourage/11.3.6.070618
On 4/2/08 02:02, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> All above just made me distraught to follow Linux semantics, and
> further thought leads me to why not let cpu_i to conduct stop process
> directly, and then let concerned cpus to call (*fn) by adding a new
> action as ***_INVOKE. By this way, cpu_i doesn't need to be cut
> off from current flow, and once stop_machine returns, all necessary
> works to be handled in a stopped environment are fulfilled.

Yes, I saw that, but it doesn't require a modified interface. The semantics
of the call are still:
 1. Synchronize/rendezvous all CPUs (the caller is assumed already to be at
a safe point and just needs to disable IRQs at the right time).
 2. Run the (*fn) on one designated CPU (via your new bit of mechanism).
 3. All done.

This fits fine within the stop_machine_run(fn, data, cpu) interface, albeit
that the underlying implementation is somewhat different (and you already
have that pretty much correct!).

Really all you need to do is put your implementation in a different file, do
some simple renaming of stuff, push some of your caller code (the bits that
create the cpumasks) into your stop_machine_run() implementation and give
stop_machine_run() the simple Linux interface.

 -- Keir
 



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