From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE Date: Tue, 03 Mar 2015 04:42:36 +0100 Message-ID: <1425354156.10194.261.camel@gmail.com> References: <1424966166-2388-3-git-send-email-wei.liu2@citrix.com> <54F0AC920200007800064BFB@mail.emea.novell.com> <20150227165139.GF29195@zion.uk.xensource.com> <54F0A0DA.8020809@citrix.com> <54F40B7E02000078000C9AE2@mail.emea.novell.com> <1425310221.21151.87.camel@citrix.com> <20150302153814.GJ11855@zion.uk.xensource.com> <54F495190200007800065383@mail.emea.novell.com> <20150302160832.GM11855@zion.uk.xensource.com> <54F49D7D020000780006540C@mail.emea.novell.com> <20150302163918.GP11855@zion.uk.xensource.com> <54F4A2F80200007800065471@mail.emea.novell.com> <54F49777.3040506@citrix.com> <54F4AB4D02000078000654F0@mail.emea.novell.com> <54F49F36.10201@citrix.com> <54F4A153.4080504@citrix.com> <54F4A255.4040200@citrix.com> <1425318759.24959.49.camel@citrix.com> <54F4A9A7.6@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5924211259523205056==" Return-path: In-Reply-To: <54F4A9A7.6@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: xen-devel@lists.xen.org, Wei Liu , Ian Campbell , Jan Beulich , David Vrabel List-Id: xen-devel@lists.xenproject.org --===============5924211259523205056== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-J5xa61RCBprLCdSUIXA0" --=-J5xa61RCBprLCdSUIXA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-03-02 at 18:19 +0000, Andrew Cooper wrote: > On 02/03/15 17:52, Ian Campbell wrote: > >> On 02/03/15 17:43, Andrew Cooper wrote: > >>> On 02/03/15 17:34, David Vrabel wrote: > >>>> A guest that previously had 2 vNUMA nodes is migrated to a host with > >>>> only 1 pNUMA node. It should still have 2 vNUMA nodes. > >>> A natural consequence of vNUMA is that the guest must expect the vNUM= A > >>> layout to change across suspend/resume. The toolstack cannot guarent= ee > >>> that it can construct a similar vNUMA layout after a migration. This > >>> includes the toolstack indicating that it was unable to make any usef= ul > >>> NUMA affinity with the memory ranges. > > In the case you mention above I would expect the 2 vnuma nodes to just > > point to the same single pnuma node. > > Right, that's still doable. But what if we have 4 nodes but none can, alone, accommodate all the memory of the guest's vnodes? (e.g., 1GB free on each pnode, guest with 2 vnodes, each 1.2GB wide.) The point being that it would be quite complicated to have to deal with all the possible variations such situations in the toolstack, especially considering that Xen smoothly handles that already (at the cost of performance, of course). > > As such I think it's probably not relevant to the need for > > XEN_NO_NUMA_NODE? > > > > Or is that not would be expected? >=20 > If we were to go down that route, the toolstack would need a way of > signalling "this vNUMA node does not contain memory on a single pNUMA > node" if there was insufficient free space to make the allocation. >=20 Exactly. BTW, about the use cases: wanting to test vNUMA without NUMA hardware, as Jan said. Also, wanting to test NUMA support in the guest OS, or in an application inside the guest, without having NUMA hardware. But much more important are the situations that Andrew and David described. > In this case, a pnode of XEN_NO_NUMA_NODE seems like precisely the > correct value to report. >=20 Indeed. It tells Xen: <>. That makes the code, IMO, simpler at any level. In fact, at Xen level, there is a default way to deal with the situation (the striping) already. At the toolstack level, we can only care about trying to come up with some super-cool and super-good (for performance) configuration and just give up, if anything like what David and Andrew said occurs. It's exactly what we're doing right now, BTW, with no vNUMA: we try to place a domain on one (or on the least possible amount of) NUMA node(s) but, if we fail, we inform the user that performance may suffer (with a WARNING), and let Xen do what it wants with the guest's memory. Regards, Dario --=-J5xa61RCBprLCdSUIXA0 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 iEYEABECAAYFAlT1LawACgkQk4XaBE3IOsQaYwCfTRXaMU5p/WhstHqYU3z0zpRz susAoKrQz6+9WZrG2l74jV0RcptrwAgI =R8Qo -----END PGP SIGNATURE----- --=-J5xa61RCBprLCdSUIXA0-- --===============5924211259523205056== 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 --===============5924211259523205056==--