On Thu, Aug 08, 2019 at 04:35:00PM +1000, David Gibson wrote: > On Wed, Aug 07, 2019 at 02:52:56PM -0300, Eduardo Habkost wrote: > > On Tue, Aug 06, 2019 at 02:50:55PM +0200, Igor Mammedov wrote: > > > On Mon, 5 Aug 2019 15:13:02 +0800 > > > Tao Xu <tao3...@intel.com> wrote: > > > > > > > Add MachineClass::auto_enable_numa field. When it is true, a NUMA node > > > > is expected to be created implicitly. > > > > > > > > Acked-by: David Gibson <da...@gibson.dropbear.id.au> > > > > Suggested-by: Igor Mammedov <imamm...@redhat.com> > > > > Suggested-by: Eduardo Habkost <ehabk...@redhat.com> > > > > Signed-off-by: Tao Xu <tao3...@intel.com> > > [...] > > > > + mc->auto_enable_numa = true; > > > > > > this will always create a numa node (that will affect not only RAM but > > > also all other components that depends on numa state (like CPUs)), > > > where as spapr_populate_memory() was only faking numa node in DT for RAM. > > > It makes non-numa configuration impossible. > > > Seeing David's ACK on the patch it might be fine, but I believe > > > commit message should capture that and explain why the change in > > > behavior is fine. > > > > After a quick look, all spapr code seems to have the same > > behavior when nb_numa_nodes==0 and nb_numa_nodes==1, but I'd like > > to be sure. > > That's certainly the intention. If there are cases where it doesn't > behave that way, it's a bug - although possible one we have to > maintainer for machine compatibility. > > > David and/or Tao Xu: do you confirm there's no ABI change at all > > on spapr after implicitly creating a NUMA node? > > I don't believe there is, no.
Oh, FWIW, the PAPR interface which is what defines the guest environment has no notion of "non NUMA" except in the sense of a system with exactly one NUMA node. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature