From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v6 00/10] vnuma introduction Date: Fri, 18 Jul 2014 12:13:36 +0200 Message-ID: <1405678416.5333.179.camel@Solace> References: <1405662609-31486-1-git-send-email-ufimtseva@gmail.com> <20140718095359.GA5687@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0382214255820591920==" Return-path: In-Reply-To: <20140718095359.GA5687@zion.uk.xensource.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: Wei Liu Cc: keir@xen.org, Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com, george.dunlap@eu.citrix.com, msw@linux.com, lccycc123@gmail.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, JBeulich@suse.com, Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============0382214255820591920== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-htENRcWvk87GXqjnA3eC" --=-htENRcWvk87GXqjnA3eC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2014-07-18 at 10:53 +0100, Wei Liu wrote: > Hi! Another new series! >=20 :-) > 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. > >=20 >=20 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) >=20 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.=20 > 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. >=20 And, apart from SMT, what topology does the guest see then? In any case, if this only alter SMT-ness (where "alter"=3D"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. >=20 wow, cool! I guess we all are! :-) Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-htENRcWvk87GXqjnA3eC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlPI81AACgkQk4XaBE3IOsTsnQCfUWZ+NezuYJMnmQt3De6g7TJF 1mcAnA3Xji3TCH1L3rI/jJ8jQAQbNRjb =x1os -----END PGP SIGNATURE----- --=-htENRcWvk87GXqjnA3eC-- --===============0382214255820591920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============0382214255820591920==--