Re: [PATCH v6 00/10] vnuma introduction

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2585 bytes --]

On ven, 2014-07-18 at 10:53 +0100, Wei Liu wrote:
> Hi! Another new series!
> 
:-)

> On Fri, Jul 18, 2014 at 01:49:59AM -0400, Elena Ufimtseva wrote:

> > The workaround is to specify cpuid in config file and not use SMT. But soon I will come up
> > with some other acceptable solution.
> > 
> 
For Elena, workaround like what?

> I've also encountered this. I suspect that even if you disble SMT with
> cpuid in config file, the cpu topology in guest might still be wrong.
>
Can I ask why?

> What do hwloc-ls and lscpu show? Do you see any weird topology like one
> core belongs to one node while three belong to another?
>
Yep, that would be interesting to see.

>  (I suspect not
> because your vcpus are already pinned to a specific node)
> 
Sorry, I'm not sure I follow here... Are you saying that things probably
works ok, but that is (only) because of pinning?

I may be missing something here, but would it be possible to at least
try to make sure that the virtual topology and the topology related
content of CPUID actually agree? And I mean doing it automatically (if
only one of the two is specified) and to either error or warn if that is
not possible (if both are specified and they disagree)?

I admit I'm not a CPUID expert, but I always thought this could be a
good solution...

> What I did was to manipulate various "id"s in Linux kernel, so that I
> create a topology like 1 core : 1 cpu : 1 socket mapping. 
>
And how this topology maps/interact with the virtual topology we want
the guest to have?

> In that case
> guest scheduler won't be able to make any assumption on individual CPU
> sharing caches with each other.
> 
And, apart from SMT, what topology does the guest see then?

In any case, if this only alter SMT-ness (where "alter"="disable"), I
think that is fine too. What I'm failing at seeing is whether and why
this approach is more powerful than manipulating CPUID from config file.

I'm insisting because, if they'd be equivalent, in terms of results, I
think it's easier, cleaner and more correct to deal with CPUID in xl and
libxl (automatically or semi-automatically).

> P.S. I'm benchmarking your v5, tell me if you're interested in the
> result.
> 
wow, cool! I guess we all are! :-)

Thanks and 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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel