[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Poor HVM performance with 8 vcpus


  • To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • From: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
  • Date: Wed, 7 Oct 2009 18:37:59 +0200
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 07 Oct 2009 09:38:18 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VbScYxJ/LxlvMn4L8JWl89zVB5TtofJSt6w3yJ8/qD/cAohPkIMgRb/AFY+Mc7Wpuf Z6Q8aqz21Hr+BtdyT5xeeXuh7OTaVNWLjoAK5CD/N0dtQS4UnllGfHfwN0L3DneaEVZ7 AbcZmsteH1zzIr7J8oxlqzSsCaVkEvUNpCA8k=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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?

Thanks,
Gianluca

> Is there a chance to split the shadow lock into sub-locks or to use a
> reader/writer lock instead?
> I just wanted to ask before trying to understand all of the shadow code :-)
>
>
> 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
>



-- 
It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.