Re: Linux warns `Unknown NUMA node; performance will be reduced`

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Jun 11, 2024 at 11:05:31AM +0800, Yunsheng Lin wrote:
> On 2024/6/11 4:27, Paul Menzel wrote:
> > Am 10.06.24 um 21:42 schrieb Bjorn Helgaas:
> >> [+cc Yunsheng, thread at
> >> https://lore.kernel.org/r/a154f694-c48b-4b3b-809f-4b74ec86a924@molgen.mpg.de]
> >> On Sun, Jun 09, 2024 at 10:31:05AM +0200, Paul Menzel wrote:
> >>> On the servers below Linux warns:
> >>>
> >>>       Unknown NUMA node; performance will be reduced
> >>
> >> This warning was added by ad5086108b9f ("PCI: Warn if no host bridge
> >> NUMA node info"), which appeared in v5.5, so I assume this isn't new.
> >>
> >> That commit log says:
> >>
> >>    In pci_call_probe(), we try to run driver probe functions on the node where
> >>    the device is attached.  If we don't know which node the device is attached
> >>    to, the driver will likely run on the wrong node.  This will still work,
> >>    but performance will not be as good as it could be.
> >>
> >>    On NUMA systems, warn if we don't know which node a PCI host bridge is
> >>    attached to.  This is likely an indication that ACPI didn't supply a _PXM
> >>    method or the DT didn't supply a "numa-node-id" property.
> >>
> >> I assume these are all ACPI systems, so likely missing _PXM.  An
> >> acpidump could confirm this.
> > 
> > I created an issue in the Linux Kernel Bugzilla [1] and attached the output of `acpidump` on a Dell PowerEdge T630 there. The DSDT contains:
> > 
> >         Device (PCI1)
> >         {
> >         […]
> >             Method (_PXM, 0, NotSerialized)  // _PXM: Device Proximity
> >             {
> >                 If ((CLOD == 0x00))
> >                 {
> >                     Return (0x01)
> >                 }
> >                 Else
> >                 {
> >                     Return (0x02)
> >                 }
> >             }
> >         […]
> >         }
> > 
> >> I think the devices on buses 7f and ff are Intel chipset devices, and
> >> I doubt we have drivers for any of them.  They have vendor/device IDs
> >> of 8086:6fXX, and I didn't see any reference to them:
> >>
> >>    $ git grep -i \<0x6f..\>
> >>    $
> > 
> > Interesting. Any ideas, what these chipset devices do?
> > 
> >> If we *did* have drivers, they would certainly benefit from having
> >> _PXM, but since there are no probe methods, I don't think it matters
> >> that we don't know where they should run.
> >>
> >> Maybe the message should be downgraded from "dev_warn" to "dev_info"
> >> since there's no functional problem, and the user can't really do
> >> anything about it.
> >>
> >> We could also consider moving it to the actual probe path, so we don't
> >> emit a message unless there is an affected driver.
> 
> The problem seems to be how we decide if there is an affected driver?
> do we care about the out-of-tree driver? doesn't the out-of-tree driver
> suffer from the similar problem if BIOS is not providing the correct
> numa info?

I don't care about out-of-tree drivers at all.  This message is only a
hint about maybe not getting the absolute best possible performance
anyway.

> The 'Unknown NUMA node; performance will be reduced' warning seems to
> be added to give the vendor some pressure to fix the BIOS as fast as
> possible, downgrading from "dev_warn" to "dev_info" or moving it to
> the actual probe path does not seems to fix the problem, just alliviate
> the pressure for vendor to fix the BIOS?

True, BIOS vendors *might* care about fixing a warning, and likely
wouldn't even notice a dev_info.

It's possible somebody could add a test case to the firmware test
suite (https://github.com/fwts/fwts.git).  Not sure if vendors care
about that either.

I suspect Linux users might care about the dev_warn because I suspect
it breaks the pretty graphical boot sequence.

As far as the Linux kernel, I think making it dev_info is enough.

Bjorn