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

RE: [Xen-devel] [Patch 2 of 2]: PV-domain SMP performance Linux-part


  • To: "'Juergen Gross'" <juergen.gross@xxxxxxxxxxxxxxxxxxx>, "'Keir Fraser'" <keir.fraser@xxxxxxxxxxxxx>
  • From: "Venefax" <venefax@xxxxxxxxx>
  • Date: Fri, 16 Jan 2009 02:38:02 -0500
  • Cc: 'George Dunlap' <George.Dunlap@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 15 Jan 2009 23:39:12 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Pj/JIhKOJzSxhDWiNMSecGihuE4Rv/zv4YdDX9iG4jSCoh8SdS5oWAGTXWeZqI3sQF amBkl2H+Dot0igq56lFWVRgCs2orAl6FniLEhXEARbcEApUe+pnWjvMFd4g0F59OGOAf SE1LhpL4cPcQ2EidvwYYsiJWMqKvOQryeRBec=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acl3qnK+xyEnNDOaSMK7+Nm0E5P1MQAAq7tA

I can test it a real-world situation.
I have SUSE 10-SP2 and have terrible performance issues with fully
virtualized SMP machines. I had to start using Standard PC as HAL to avoid
the penalty.
Federico


-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Juergen Gross
Sent: Friday, January 16, 2009 2:16 AM
To: Keir Fraser
Cc: George Dunlap; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [Patch 2 of 2]: PV-domain SMP performance
Linux-part

Keir Fraser wrote:
> On 19/12/2008 09:25, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxxxxxxx>
> wrote:
> 
>>> I haven't seen any win on any real world setup. So I remain unconvinced,
and
>>> it'll need more than you alone championing the patch to get it in. There
>>> have been no other general comments so far (Jan's have been about
specific
>>> details).
>> Okay, would the following scenario be "real world" enough?
>>
>> Multiple domUs being busy leading to enough vcpu scheduling, several
parallel
>> kernel builds in dom0 acting as benchmark.
> 
> Something like that would be better. Of course you'd need to measure work
> done in the domUs as well, as one of the critical factors for this patch
> would be how it affects fairness. It's one reason I'm leery of this patch
--
> our scheduler is unpredictable enough as it is without giving domains
> another lever to pull!

Keir, is the data I posted recently okay?
I think my approach requires less changes than the "yield after spin"
variant,
which needed more patches in the hypervisor and didn't seem to be settled.
Having my patches in the hypervisor at least would make life much easier for
our BS2000 system...
I would add some code to ensure a domain isn't misusing the new interface.

Juergen

-- 
Juergen Gross                             Principal Developer
IP SW OS6                      Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers         e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details:
www.fujitsu-siemens.com/imprint.html

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


_______________________________________________
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®.