On Tue, Dec 30, 2025 at 10:55:02AM +0800, Huang, FangSheng (Jerry) wrote: > Hi Gregory, > > > Sorry i've missed prior versions, is numa the right place to put this, > > considering that the node is not necessarily 100% SPM on a real system? > > > > The decision to add `spm=` to NUMA rather than the memory backend was based > on > earlier feedback from David during our initial RFC discussions. > > David raised a concern that if we put the spm flag on the memory backend, a > user > could accidentally pass such a memory backend to DIMM/virtio-mem/boot > memory, > which would have very undesired side effects. >
This makes sense, and in fact I almost wonder if we should actually encode a warning in linux in general if a signal NUMA node contains both normal and SPM. That would help drive consistency between QEMU/KVM and real platforms from the direction of linux. > > (in practice it should be, but not technically required to be) > > You're right that on a real system, a NUMA node is not technically required > to > be 100% SPM. However, in AMD's use case, the entire NUMA node memory (backed > by > memdev) is intended to be SPM, and this approach provides a cleaner and > safer > configuration interface. > I figured this was the case, and honestly this just provides more evidence that any given NUMA node probably should only have 1 "type" of memory (or otherwise stated: uniform access within a node, non-uniform across nodes). --- bit of an aside - but at LPC we also talked about SPM NUMA nodes: https://lore.kernel.org/linux-mm/[email protected]/ Would be cool to be able to detect this in the drivers and have hotplug automatically mark a node SPM unless a driver overrides it. (MHP flag? Sorry David :P) > > > > ~Gregory > > Please let me know if you have further concerns or suggestions. > I'll look at the patch details a bit more, but generally I like the direction - with an obvious note that I have a biased given the above. ~Gregory
