From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: PV-vNUMA issue: topology is misinterpreted by the guest Date: Fri, 17 Jul 2015 14:17:42 -0400 Message-ID: <55A946C6.8000002@oracle.com> References: <1437042762.28251.18.camel@citrix.com> <55A7A7F40200007800091D60@mail.emea.novell.com> <55A78DF2.1060709@citrix.com> <20150716152513.GU12455@zion.uk.xensource.com> <55A7D17C.5060602@citrix.com> <55A7D2CC.1050708@oracle.com> <55A7F7F40200007800092152@mail.emea.novell.com> <55A7DE45.4040804@citrix.com> <55A7E2D8.3040203@oracle.com> <55A8B83802000078000924AE@mail.emea.novell.com> <1437118075.23656.25.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGAD7-0008Jf-Uu for xen-devel@lists.xenproject.org; Fri, 17 Jul 2015 18:18:14 +0000 In-Reply-To: <1437118075.23656.25.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Jan Beulich Cc: Elena Ufimtseva , Wei Liu , Andrew Cooper , David Vrabel , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org On 07/17/2015 03:27 AM, Dario Faggioli wrote: > On Fri, 2015-07-17 at 07:09 +0100, Jan Beulich wrote: >>>>> On 16.07.15 at 18:59, wrote: >>> And in general (both for PV and HVM) --- is there any reason to expose >>> CPU topology at all? I can see it being useful if VCPUs are pinned but >>> if they are not then it can make performance worse. >> Indeed >> > Indeed indeed. :-) > > And in fact, this is even independent from vNUMA. Yet, I remember we > were discussing about this since the beginning of vNUMA work, back when > it was Elena doing it, but the it seems we all forgot... Sorry for > that! :-/ > > I seriously think we should do something about this as, while in a non > vNUMA setup it can certainly cause weird/inconsistent performance, in a > vNUMA one, as shown, it's quite a hige mess. > >> - that's what our kernels have been doing for years, and >> it seems like someone over here is now looking into whether this >> could be done in pv-ops too (without too much uglification). >> > That would be great, IMO. I'd be up for helping with this, but I know > next to nothing about CPUID, so that would require some setup time. If, > at least, you could keep me in the loop it would be great. > > In the meanwhile, what should we do? Document this? How? "don't use > vNUMA with PV guest in SMT enabled systems" seems a bit harsh... Is > there a workaround we can put in place/suggest? I haven't been able to reproduce this on my Intel box because I think I have different core enumeration. Can you try adding cpuid=['0x1:ebx=xxxxxxxx00000001xxxxxxxxxxxxxxxx'] to your config file? On AMD, BTW, we fail a different test so some other bits probably need to be tweaked. You may fail it too (the LLC sanity check). -boris