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: Wed, 29 Jul 2009 08:14:05 +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: Tue, 28 Jul 2009 23:14:35 -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=1248847976; x=1280383976; 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:=20Wed,=2029=20Jul=202009=2008:14:05=20+0200 |Message-ID:=20<4A6FE8AD.3020308@xxxxxxxxxxxxxx>|To:=20Ke ir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx>|CC:=20George=20 Dunlap=20<dunlapg@xxxxxxxxx>,=20=0D=0A=20Tim=20Deegan=20< Tim.Deegan@xxxxxxxxxxxxx>,=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< C694C1D6.10B73%keir.fraser@xxxxxxxxxxxxx>|References:=20< C694C1D6.10B73%keir.fraser@xxxxxxxxxxxxx>; bh=EGMQA+iX8b3A02vmPRMH6fq9mHy6Wfmi252FEFz7qdQ=; b=T6KZPYyFP7vJo+92HAC39PMl4Yi86oysvgRkpg2xNVWl5QS04MzPFebZ GmA3ux9TJ6kJU/DSebGNqazIJYJAYUsQgmGbWWvVrk8GISfzLQZ/epalJ SF1efr6rRoTucNPGAxuIxioBajirEoTt8vvGUC8nhHTrKpgxed3ldDgPy 6X8JLd2jSzEMqKvhweXPu/wsaRyBLtezaV9YZ8sBFN4j6T4ymJHjwepNU mLnJeAXzbrpGQA2ZQBjn197B9dDrC;
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=ezZiaOBnlyianC9ZYVIuGdCT9iwzKRfxbwCIBh2CpJFXiG0qQrDykeb4 aADWF2YH8KF19NEhKTuCcsgwHuwCZrpEnOtAxojpgFcT49+JDphiWu7aa Q7Q4X+BfQiZ4r7cSCITj32cFN92wmhiNSIb8jHLi7GRwN0R1CMkbQz5X2 ik3Y00e2V28iu4VfOsUaEJVMHZJe2Yzm/JYsBakkEzNNW1N1fJXCRB3Th DZSx872jkvn1rUDR+hSvzYtED9cGj;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C694C1D6.10B73%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: <C694C1D6.10B73%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
Keir Fraser wrote:
> On 28/07/2009 14:41, "George Dunlap" <dunlapg@xxxxxxxxx> wrote:
> 
>> As Juergen says, for people who don't use the feature, it shouldn't
>> have any real effect.  The patch is pretty straightforward, except for
>> the "continue_hypercall_on_cpu()" bit.
> 
> Just pulled up the patch. Actually cpupool_borrow_cpu() does not seem to
> lock down the cpu-pool-vcpu relationship while continue_hypercall_on_cpu()
> is running. In particular, it is clear that it does nothing if the vcpu is
> already part of the pool that the domain is running in. But then what if the
> cpu is removed from the pool during the borrow_cpu()/return_cpu() critical
> region? It hardly inspires confidence.

I checked the use cases.
All calls leading to cpupool_borrow_cpu() are done under the domctl lock.
The same applies to all cpupool operations.
I can add an explicit check not to unassign borrowed cpus, if you like.

> 
> Another thing I noted is that sched_tick_suspend/resume are pointlessly
> changed to take a cpu parameter, which is smp_processor_id(). I swear at the
> screen whenever I see people trying to slip that kind of nonsense in. It

Sorry, this seems to be an artefact of an earlier version of my changes.
I'll remove this one...

> makes it look like the functions can operate on an arbitrary cpu when in
> fact I'll wager they cannot (and I doubt the author of such changes has
> checked). It's a nasty nasty interface change.

I'm pretty sure they could indeed work on any cpu. At least I tried to use
them on other cpus, but I ran into other problems leading to the current
solution not requiring the cpu parameter any more.


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