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] Cpu pools discussion

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Cpu pools discussion
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Fri, 31 Jul 2009 07:25:37 +0200
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, George Dunlap <dunlapg@xxxxxxxxx>, Zhigang Wang <zhigang.x.wang@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 30 Jul 2009 22:26:09 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1249017940; x=1280553940; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Juergen=20Gross=20<juergen.gross@xxxxxxxxxxxxxx> |Subject:=20Re:=20[Xen-devel]=20Cpu=20pools=20discussion |Date:=20Fri,=2031=20Jul=202009=2007:25:37=20+0200 |Message-ID:=20<4A728051.4010807@xxxxxxxxxxxxxx>|To:=20Ke ir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx>|CC:=20Tim=20Dee gan=20<Tim.Deegan@xxxxxxxxxxxxx>,=20=0D=0A=20George=20Dun lap=20<dunlapg@xxxxxxxxx>,=0D=0A=20Zhigang=20Wang=20<zhig ang.x.wang@xxxxxxxxxx>,=20=0D=0A=20"xen-devel@xxxxxxxxxxx urce.com"=20<xen-devel@xxxxxxxxxxxxxxxxxxx>|MIME-Version: =201.0|Content-Transfer-Encoding:=207bit|In-Reply-To:=20< C6975C18.10F02%keir.fraser@xxxxxxxxxxxxx>|References:=20< C6975C18.10F02%keir.fraser@xxxxxxxxxxxxx>; bh=UJL+J6mEVQxpEHwH7A034WeRuhP/vIAyUy0oEV40WNk=; b=AUhfVu5JFYbfDrR8qlOUwxkMoAyChxp9Kx0u8TxRtAvOs8JyqR62Ph0q Mh40+28zn+AREoMOKk2Bm56J1ihGpva1E4rJYD1cEFL2LLSBcGea6CYzj 6HiPq8WUpCCo0ZLTeTLtq4LFlh4bYxeX+jCYuXfp9NuQkB+x6xUK8BNmf oWpeLLX3oiyJ8u3iRqhEtoFJvbhYGvPziKEY/QQmUWPSjRcXsf73JcNu0 eef9EnEk3hsSVVrkOmTiu/ZPLIKAp;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=KrEy6Vru8dUHx9gtta276eRCzcm6j3KLr5SWVqq13eN61tkztVcv2Vgi 1Yl6Ovtvol2ZQq5WWgRHpbs83qRxvafcA+cFbe7DODSRwre5BiEp1sMiO u2hrzmVvjHvLtdzrzxVR2tDLCNfHpaA0fMVp+Y8DDWamuCcBqbOxKJrBy 1W11bO+DPg2rqA72CB/vn6CsHw2yf3y2ZUQaAStkCn2oQIHZsyF/SpPrw gcHpdu8eDe3uXKwntsbjlVeo4D84H;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C6975C18.10F02%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>
Organization: Fujitsu Technology Solutions
References: <C6975C18.10F02%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
Keir Fraser wrote:
> On 30/07/2009 13:51, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:
> 
>>> I think especially if cpupools are added into the mix then this becomes more
>>> attractive than the current approach. The other alternative is to modify the
>>> two existing problematic callers to work okay from softirq context (or not
>>> need continue_hypercall_on_cpu() at all, which might be possible at least in
>>> the case of CPU hotplug). I would be undecided between these two just now --
>>> it depends on how easily those two callers can be fixed up.
>> I'll try to set up a patch to add a hypervisor domain. Regarding all the
>> problems I got with switching cpus between pools (avoid running on the cpu to
>> be switched etc.) this solution could make life much easier.
> 
> I'm inclined actually to think a hypervisor domain is not necessary, and we
> can get by with softirqs. I actually think cpu offline can be reimplemented
> without softirqs or continue_hypercall_on_cpu(), and I would imagine cpupool
> changes then could use a similar technique. I will take a look at that, and
> you can take your cues from it if I find an elegant solution along those
> lines.

Thanks, that's great!


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@xxxxxxxxxxxxxx
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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