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@xxxxxxxxxxxxx] > >> 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
