On Wed, May 11, 2022 at 7:24 PM Jonathan Lemon <jonathan.lemon@xxxxxxxxx> wrote: > > This reverts commit a62d07e0006a3a3ce77041ca07f3c488ec880790. > > The change calls pxm_to_node(), which ends up returning -1 > (NUMA_NO_NODE) on some systems for the pci bus, as opposed > to the prior call to acpi_map_pxm_to_node(), which returns 0. > > The default numa node is then inherited by all pci devices, and is > visible in /sys/bus/pci/devices/*/numa_node > > The prior behavior shows: > # cat /sys/bus/pci/devices/*/numa_node | sort | uniq -c > 122 0 > > While the new behavior has: > # cat /sys/bus/pci/devices/*/numa_node | sort | uniq -c > 1 0 > 121 -1 > > While arguably NUMA_NO_NODE is correct on single-socket systems which > have only one numa domain, this breaks scripts that attempt to read the > NIC numa_node and pass that to numactl in order to pin memory allocation > when running applications (like iperf). E.g.: > > # numactl -p -1 iperf3 > libnuma: Warning: node argument -1 is out of range > <-1> is invalid > > Reverting this change restores the prior behavior. Well, that's not a recent commit and it fixed a real and serious issue. Isn't there a way to fix this other than reverting it? > > Signed-off-by: Jonathan Lemon <jonathan.lemon@xxxxxxxxx> > --- > drivers/acpi/numa/srat.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c > index 3b818ab186be..f150c5c1d0a8 100644 > --- a/drivers/acpi/numa/srat.c > +++ b/drivers/acpi/numa/srat.c > @@ -564,6 +564,6 @@ int acpi_get_node(acpi_handle handle) > > pxm = acpi_get_pxm(handle); > > - return pxm_to_node(pxm); > + return acpi_map_pxm_to_node(pxm); > } > EXPORT_SYMBOL(acpi_get_node); > -- > 2.30.2 >
