From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v6 02/23] xen: move NUMA_NO_NODE to public memory.h as XEN_NUMA_NO_NODE Date: Mon, 2 Mar 2015 18:19:19 +0000 Message-ID: <54F4A9A7.6@citrix.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1425318759.24959.49.camel@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: Ian Campbell , David Vrabel Cc: Wei Liu , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 02/03/15 17:52, Ian Campbell wrote: > On Mon, 2015-03-02 at 17:48 +0000, David Vrabel 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 vNUMA >>> layout to change across suspend/resume. The toolstack cannot guarentee >>> that it can construct a similar vNUMA layout after a migration. This >>> includes the toolstack indicating that it was unable to make any useful >>> NUMA affinity with the memory ranges. >> Eep! I very much doubt we can do anything in Linux except retain the >> existing NUMA layout across a save/restore. > In the case you mention above I would expect the 2 vnuma nodes to just > point to the same single pnuma node. > > As such I think it's probably not relevant to the need for > XEN_NO_NUMA_NODE? > > Or is that not would be expected? 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. In this case, a pnode of XEN_NO_NUMA_NODE seems like precisely the correct value to report. ~Andrew