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: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 1/4] CPU online/offline support in Xen
From: "Haitao Shan" <maillists.shan@xxxxxxxxx>
Date: Wed, 10 Sep 2008 20:59:10 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Shan, Haitao" <haitao.shan@xxxxxxxxx>
Delivery-date: Wed, 10 Sep 2008 05:59:35 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=paVU71fWjXIF2ES5yJEf+4UB3dqzk2fI836Yu62CplI=; b=GfcnG7cCsPJ0Ta0pNtWuMQpz8FrF7sxytFA/zl0rKZXpfVg0khzRPlqZGJxOmrlKII dU1KgyPBQMjTBm7+VBNIKdEYDkRgMBKFM9gmN7YUtXEUGeqWkS+mOJlaAXCX3gCT4H0e dOkw2d5QCQ3pLEO1p7E05eqleqW5fYZ08U8LI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=S1F6N1urmc0i5cMAgOt+NVKqUaSYHkgOWb+KHk6bp5tNdzGobcPWEDs9mUm82RngPg UChSB0P499HrHsMWx1bfOKtesf4H7Pa/VRyuL/kuYbYp7DdRZUJ3ZrRtbKGSYVFmw+0D pA5riIQuRQeF8AkoBnNZivEPJ7Rp+unO+SHYQ=
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>
References: <823A93EED437D048963A3697DB0E35DE01BE83CC@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C4ED6370.26F21%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Agree. Placing migration in stop_machine context will definitely make
our jobs easier. I will start making a new patch tomorrow. :)
I place the migraton code outside the stop_machine_run context, partly
because I am not quite sure how long it will take to migrate all the
vcpus away. If it takes too much time, all useful works are blocked
since all cpus are in the stop_machine context. Of course, I borrowed
the ideas from kernel, which also let me made the desicion.

2008/9/10 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
> 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.
>  -- Keir
> On 9/9/08 09:59, "Shan, Haitao" <haitao.shan@xxxxxxxxx> wrote:
>> This patch implements cpu offline feature.
>> Best Regards
>> Haitao Shan
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list