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] Poor HVM performance with 8 vcpus

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Poor HVM performance with 8 vcpus
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Wed, 14 Oct 2009 10:16:25 +0200
Cc: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Oct 2009 01:17:00 -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=1255508044; x=1287044044; 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]=20Poor=20HVM=20performance =20with=208=20vcpus|Date:=20Wed,=2014=20Oct=202009=2010:1 6:25=20+0200|Message-ID:=20<4AD588D9.4040104@xxxxxxxxxxxx om>|To:=20Juergen=20Gross=20<juergen.gross@xxxxxxxxxxxxxx >|CC:=20Gianluca=20Guida=20<gianluca.guida@xxxxxxxxxxxxx> ,=20=0D=0A=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel @lists.xensource.com>|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4ACD90 7F.7030505@xxxxxxxxxxxxxx>|References:=20<4ACC3B49.406050 0@xxxxxxxxxxxxxx>=20<f8877f640910070937w1f055672s1b2ec84f 5e218b28@xxxxxxxxxxxxxx>=20<4ACD907F.7030505@xxxxxxxxxxxx om>; bh=Kyg5geqeKETE0oIm3c6z5s12nZiQdH8IaObxP3jfO9c=; b=K/qtw5CujYEN+G6lLn1pi/oeBmVy8lLXDvoAOiXie0rhxaj6GzlTlqwV 2G/GZjNowtys+l5GmqSpYK+51jHm79G3C8UKKUHK003sUXAi3aYR8oiKF FbWVPzMWOJJcDRaNIVD9WrBIxBFy+z0OSSYuZ1bc4jKO1cNM+wdyoMpXd K7THviuyshUwJOSbYhyIIHefWM/0WBXppjIVMrhg5+oiRDxetpmzVizBo c+RpjBWwF8i5EKA3CPrLsyeX69hYl;
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=RNz0uPDN5DcKK3Z8ICOpFCVYVj4DV6dtd4jvXMt/Q4Q5H9TG2fkeD0iH LiZNhCG+8jW5szl/TnDmZmXYb8BoJBKKV0g2E2n+FoWTYnv6qYUHC4v2F E4rc3E2PBJZxcnZJLJZdthWo2S/qfLSrtOZ8d83bvVQFVHOEVXXaIZHVx 9Fsk+CKMhfwyvDnQZG3pCHthsfYV6+yyudMfa+Zu+nckLsC2JfGJm/Bc0 y12cogOU8+t9EzPBGM/kR38NnZbaw;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4ACD907F.7030505@xxxxxxxxxxxxxx>
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: <4ACC3B49.4060500@xxxxxxxxxxxxxx> <f8877f640910070937w1f055672s1b2ec84f5e218b28@xxxxxxxxxxxxxx> <4ACD907F.7030505@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
Gianluca,

as the performance of BS2000 seems to be hit by OOS optimization, I'm
thinking of making a patch to disable this feature by a domain parameter.

Is there a way to do this without having to change all places where the
#if statements are placed?
I think there should be some central routines where adding an "if" could
be enough (setting oos_active to 0 seems not to be enough, I fear).

Do you have any hint?


Juergen

Juergen Gross wrote:
> Hi,
> 
> Gianluca Guida wrote:
>> Hi,
>>
>> On Wed, Oct 7, 2009 at 8:55 AM, Juergen Gross
>> <juergen.gross@xxxxxxxxxxxxxx> wrote:
>>> we've got massive performance problems running a 8 vcpu HVM-guest (BS2000)
>>> under XEN (xen 3.3.1).
>>>
>>> With a specific benchmark producing a rather high load on memory management
>>> operations (lots of process creation/deletion and memory allocation) the 8
>>> vcpu performance was worse than the 4 vcpu performance. On other platforms
>>> (/390, MIPS, SPARC) this benchmark scaled rather well with the number of 
>>> cpus.
>>>
>>> The result of the usage of the software performance counters of XEN seemed
>>> to point to the shadow lock being the reason. I modified the Hypervisor to
>>> gather some lock statistics (patch will be sent soon) and found that the
>>> shadow lock is really the bottleneck. On average 4 vcpus are waiting to get
>>> the lock!
>>>
>>> Is this a known issue?
>> Acutally, I think so. The OOS optimization is widely known not to be
>> too scalable at 8vcpus in the current state, since its weak point is
>> the CR3 switching time increasing linearly with the number of cpus. If
>> you have lot of processes switches together with lot of PTE writings
>> (as it seems to be the case for your benchmark) then that's probably
>> the cause.
>>
>> Could you try disabling the OOS optimization from the
>> SHADOW_OPTIMIZATIONS definition?
> 
> Great!
> First performance data looks okay!
> We will have to run different benchmarks in different configurations, but I
> think you gave an excellent hint. :-)


-- 
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