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] Re: [PATCH 1/4] CPU online/offline support in Xen

To: "Shan, Haitao" <haitao.shan@xxxxxxxxx>, Haitao Shan <maillists.shan@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 11 Sep 2008 17:52:31 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 11 Sep 2008 09:53:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <823A93EED437D048963A3697DB0E35DE01C1EB9B@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckTRQdBPwPE1uAaTHujwHsOZlG02QAgVtYgAA47ZqAAAGuaQAAF9BQsAAMUy1AAAmluzw==
Thread-topic: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
User-agent: Microsoft-Entourage/
On 11/9/08 17:00, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:

> Hi, Keir,
> Concerning the last running vcpu on the dying cpu, I have some thought.
> Yes, there would be a short time after the stop_machine_run when this vcpu
> v->processor == dying_cpu. But anyhow, we set fie __VPF_migrating flag for
> that vcpu and issued a schedule_softirq on the dying cpu.
> This softirq should run immediately after stop_machine context, am I right? If
> so, by the time the schedule softirq is executed, this last vcpu is migrated
> away from this dying cpu. But saving of its context will be delayed to
> play_dead->sync_lazy_context.
> If another cpu issues the schedule request to this dying cpu
> (vcpu_sleep_nosync->cpu_raise_softirq(vc->processor....)) during this time,
> the request will be serviced by the above code sequence. So it is safe in such
> cases.
> Am I missing something important? I am not quite confident on the statements,
> though.

I agree it looks safe.

By the way, have you considered using this hotplug functionality for power
management? If instead of for(;;) halt(); we instead hooked into Cx
management and tried to get into as deep sleep as possible (possibly even
supporting the really deep sleeps that power off a whole socket and mean you
*have* to come back via real mode) then this would give a nice
coarse-time-scale power management mechanism controllable from dom0.

I consider this might be a nice win for possibly less effort than is being
expended in trying to make idle residency times (and hence Cx residency
times) as long as possible.

 -- Keir

Xen-devel mailing list