On Fri, Mar 23, 2018 at 4:08 PM, Ross Zwisler
For systems that don't support NUMA, numactl gives a loud and
# numactl -N 0 ls
numactl: This system does not support NUMA policy
Follow this model in ndctl for NUMA based filtering:
# ./ndctl/ndctl list --numa-node=0
Error: This system does not support NUMA
This is done instead of just quietly filtering out all dimms, regions and
namespaces because the NUMA node they were trying to match didn't exist in
libnuma tests whether NUMA is enabled via the get_mempolicy() syscall,
passing in all NULLs and 0s for arguments to always get the default policy.
See numa_available() in numa(3) and in the numactl source.
ndctl checks sysfs for the existence of the /sys/devices/system/node
directory to avoid a dependency on libnuma. If we had a dependency on
libnuma we would have to choose whether this was fulfilled or not at
compile time, which would potentially mean that we could be on a
NUMA-enabled kernel but with an ndctl where NUMA support was disabled.
It's better to always have NUMA support in ndctl and only depend on the
I've inspected the code for both get_mempolicy() and the code that creates
the /sys/devices/system/node directory, and they both seem to completely
rely on CONFIG_NUMA being defined. If CONFIG_NUMA is set, get_mempolicy()
will always be able to return a default policy and /sys/devices/system/node
will always exist. Otherwise, both checks will always fail. So, numactl
and ndctl should always agree on whether NUMA is supported on a given
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Suggested-by: Dan Williams <dan.j.williams(a)intel.com>
v3: Changed back to checking /sys/devices/system/node instead of using
libnuma, and added more info to the changelog.
Looks good, applied.