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>
Subject: Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 10 Sep 2008 11:59:01 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 10 Sep 2008 03:59:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C4ED6370.26F21%keir.fraser@xxxxxxxxxxxxx>
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: AckSWmKh0QG0bsOOQWqAjPJM8eBXpwA17YJnAACIpV4=
Thread-topic: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
User-agent: Microsoft-Entourage/
On 10/9/08 11:43, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> I feel this is more complicated than it needs to be.
> How about clearing VCPUs from the offlined CPU's runqueue from the very end
> of __cpu_disable()? At that point all other CPUs are safely in softirq
> context with IRQs disabled, and we are running on the correct CPU (being
> offlined). We could have a hook into the scheduler subsystem at that point
> to break affinities, assign to different runqueues, etc. We would just need
> to be careful not to try an IPI. :-) This approach would not need a
> cpu_schedule_map (which is really increasing code fragility imo, by creating
> possible extra confusion about which cpumask is the wright one to use in a
> given situation).
> My feeling, unless I've missed something, is that this would make the patch
> quite a bit smaller and with a smaller spread of code changes.

Another thought: we may (appear to) need an IPI after VCPUs have been
migrated to other runqueues. And actually that will be safe because
smp_send_event_check_cpu() is non-blocking (does not wait for the remote CPU
to run the IPI handler). So it *is* safe to do non-blocking IPIs from
stop_machine_run() context.

 -- Keir

Xen-devel mailing list