Re: PV-vNUMA issue: topology is misinterpreted by the guest

[Wei Liu <wei.liu2@citrix.com>]

On Fri, Jul 17, 2015 at 09:27:55AM +0200, Dario Faggioli wrote:
> On Fri, 2015-07-17 at 07:09 +0100, Jan Beulich wrote:
> > >>> On 16.07.15 at 18:59, <boris.ostrovsky@oracle.com> 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?
> 

Don't worry. PV vNUMA kernel patch is not upstreamed. :-P

This is one of the issues that is not upstreamed. The other issue is my
own laziness...

Wei.

> Regards,
> Dario
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)