From: Bjorn Helgaas <helgaas@kernel.org>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Yunsheng Lin <linyunsheng@huawei.com>
Subject: Re: Linux warns `Unknown NUMA node; performance will be reduced`
Date: Tue, 11 Jun 2024 10:11:02 -0500 [thread overview]
Message-ID: <20240611151102.GA963259@bhelgaas> (raw)
In-Reply-To: <4dcdc648-e09d-4f43-a53c-bcb4f54ef476@molgen.mpg.de>
On Mon, Jun 10, 2024 at 10:27:37PM +0200, Paul Menzel wrote:
> Am 10.06.24 um 21:42 schrieb Bjorn Helgaas:
> > 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)
> }
> }
> […]
> }
This machine (the T630, from your first message) has several PCI host
bridges:
ACPI: PCI Root Bridge [UNC1] (domain 0000 [bus ff])
pci_bus 0000:ff: root bus resource [bus ff]
ACPI: PCI Root Bridge [UNC0] (domain 0000 [bus 7f])
pci_bus 0000:7f: root bus resource [bus 7f]
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
pci_bus 0000:00: root bus resource [io 0x0000-0x03bb window]
pci_bus 0000:00: root bus resource [io 0x03bc-0x03df window]
pci_bus 0000:00: root bus resource [io 0x03e0-0x0cf7 window]
pci_bus 0000:00: root bus resource [io 0x1000-0x7fff window]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
pci_bus 0000:00: root bus resource [mem 0x90000000-0xc7ffbfff window]
pci_bus 0000:00: root bus resource [mem 0x38000000000-0x3bfffffffff window]
pci_bus 0000:00: root bus resource [bus 00-7e]
ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-fe])
pci_bus 0000:80: root bus resource [io 0x8000-0xffff window]
pci_bus 0000:80: root bus resource [mem 0xc8000000-0xfbffbfff window]
pci_bus 0000:80: root bus resource [mem 0x3c000000000-0x3ffffffffff window]
pci_bus 0000:80: root bus resource [bus 80-fe]
PCI0 and PCI1 lead to all your normal PCI devices, they both
implement _PXM, and they have all the usual apertures for PCI I/O and
MMIO space where device BARs live.
UNC0 and UNC1 lead to these special chipset devices, they don't
implement _PXM, and they don't have any resources except the bus
number. The devices on bus 7f and ff can only be used via config
space accesses, and I have no idea what they are used for.
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218951
next prev parent reply other threads:[~2024-06-11 15:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-09 8:31 Linux warns `Unknown NUMA node; performance will be reduced` Paul Menzel
2024-06-10 19:42 ` Bjorn Helgaas
2024-06-10 20:27 ` Paul Menzel
2024-06-11 3:05 ` Yunsheng Lin
2024-06-11 22:31 ` Bjorn Helgaas
2025-08-05 21:39 ` Paul Menzel
2024-06-11 15:11 ` Bjorn Helgaas [this message]
2024-06-18 15:19 ` Paul Menzel
2026-03-03 21:55 ` Bjorn Helgaas
2026-03-04 1:34 ` Yunsheng Lin
2026-03-04 21:18 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240611151102.GA963259@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=pmenzel@molgen.mpg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.