From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: PV-vNUMA issue: topology is misinterpreted by the guest Date: Mon, 27 Jul 2015 15:11:43 +0200 Message-ID: <1438002703.5036.112.camel@citrix.com> References: <55AFA16B.3070103@oracle.com> <55AFA41E.1080101@suse.com> <55AFAC34.1060606@oracle.com> <55B070ED.2040200@suse.com> <1437660433.5036.96.camel@citrix.com> <55B21364.5040906@suse.com> <1437749076.4682.47.camel@citrix.com> <55B25650.4030402@suse.com> <55B258C9.4040400@suse.com> <1437753509.4682.78.camel@citrix.com> <20150724160948.GA2067@l.oracle.com> <55B60C9C.9020405@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4682478140439435304==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJiCA-0006I3-Cr for xen-devel@lists.xenproject.org; Mon, 27 Jul 2015 13:11:54 +0000 In-Reply-To: <55B60C9C.9020405@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: Andrew Cooper Cc: Juergen Gross , Elena Ufimtseva , Wei Liu , George Dunlap , David Vrabel , Jan Beulich , "xen-devel@lists.xenproject.org" , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org --===============4682478140439435304== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Joabg+GMKnv1DEHMu5yD" --=-Joabg+GMKnv1DEHMu5yD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-07-27 at 11:49 +0100, Andrew Cooper wrote: > On 27/07/15 11:41, George Dunlap wrote: > > Can you expand a little on this? I'm having trouble figuring out > > exactly what user-space applications are reading and how they're using > > it -- and, how they work currently in virtual environments, given that > > they (typically) will be moved between physical processors even if > > they stay on the same virtual processor. >=20 > There are many examples of userspace application using cpuid to modify > themselves. Any serious application with processor optimisations will > use the cpuid feature bits to choose the most efficient algorithm. >=20 > hwloc is an perfect example which gathers all of the topology > information out of cpuid to work out how to most efficiently > pin/schedule tasks. >=20 And all of this is broken, right now, isn't it? Where, saying this, I'm aiming at stressing the point (as the thread is starting to become a bit hard to follow) that we must come up with a decent solution, working reasonably well in a bunch of (conflicting! *sigh*) scenarios, *not* to implement something new without breaking what we have, as what we have is broken already! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Joabg+GMKnv1DEHMu5yD 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 iEYEABECAAYFAlW2Lg8ACgkQk4XaBE3IOsTmkQCfdibWD1PH3XIOE5NkUSkjzKVB C5gAn37U7p1GTPIJs3/WPVMj504csCYh =0oqE -----END PGP SIGNATURE----- --=-Joabg+GMKnv1DEHMu5yD-- --===============4682478140439435304== 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 --===============4682478140439435304==--