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/
Home Products Support Community News


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 11:01:40 +0000
Delivery-date: Mon, 04 Feb 2008 03:01:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D8F4D@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/AAEgPSQAALcyqI=
Thread-topic: [Xen-devel] [PATCH] Rendezvous selected cpus
User-agent: Microsoft-Entourage/
Much better. I think this will go in, although I might rename some more
stuff inside stop_machine.c towards Linux stop_machine-style names.

 -- Keir

On 4/2/08 09:51, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Then, attach updated version per your comments, with Linux
> stop_machine semantics kept in common place. Build tested
> for x86, and ideally it should also work on other archs.
> One small issue is about the lock handle with cpu hotplug.
> For cpu hotplug request from control tools, there's a dead lock
> race between pure cpu hotplug path and stop machine if we
> still use spinlock as the guard. For example, stop_machine
> may hold lock on one cpu, and wait response from another
> one who happnes to spin loop on lock per hotplug request.
> In that case, the other cpu gets no chance to handle softirq.
> We may be able to use trylock for cpu_up/down, however
> that also affects stop_machine like called from S3 path for
> which try-and-give-up is too heavy and unexpected. Maybe
> some new cpu_tryup/trydown may be used. Not sure...
> But anyway, still some way to go for a full cpu hotplug support
> which doesn't prevent this feature to slip in based on spinlock
> at this stage. :-)
> More comments?
> Thanks,
> Kevin
>> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>> Sent: 2008年2月4日 15:31
>> 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