[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v6 00/10] vnuma introduction
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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |