linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Ulrich Drepper <drepper@gmail.com>,
	jbarnes@virtuousgeek.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	lenb@kernel.org, x86@kernel.org, linux-pci@vger.kernel.org
Subject: Re: SNB PCI root information
Date: Sat, 16 Jun 2012 15:56:28 -0600	[thread overview]
Message-ID: <CAErSpo57H_ZD_-Z8z9vD3c50My4Rejtc9gXXrxGxDtQomYmrSA@mail.gmail.com> (raw)
In-Reply-To: <CAE9FiQU=Uvj_OFYQLdddf8j59vE7D0aE9cdNZv7P8_Rn7=MmUQ@mail.gmail.com>

On Fri, Jun 15, 2012 at 9:03 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, Jun 15, 2012 at 6:57 PM, Ulrich Drepper <drepper@gmail.com> wrote:
>> The PCI roots in multi-socket SNB are part of specific sockets.  This
>> means optimization will need to know which socket the root is part of
>> and therefore which cores have direct access as opposed to over one or
>> more QPI links.
>>
>> I tried to find this information in the /sys filesystem in kernels up
>> to the current upstream kernel.  It seems there is actually nothing
>> like this.
>>
>> There are the files /sys/devices/pci*/*/local_cpus which should
>> contain this information.  For each device we would be able to get the
>> information about the local CPUs.
>>
>> The SPARC OF handling seems to set the field, some Intel drivers seem
>> to try to do it in a different way.
>>
>> The problem I have seen (at least on a Dell R620) is that the
>> dev_to_code() function returns -1 which indicates that no node
>> information is stored.
>>
>> If I understand the code correctly, the numa_node field can be set
>> explicitly but is mostly inherited from the underlying device (bus
>> etc).  Does this mean that the locality information should come from
>> the same place where the PCI root data structure is initialized?
>>
>> This happens, if I'm not mistaken, in the ACPI table parsing.  I've
>> disassembled the DSDT table and didn't find anything like this type of
>> information.  At least I didn't see it.  I also couldn't find anything
>> in the ACPI 5.0 spec.
>
> yes, you should have _PXM for root bus in DSDT.
>
>>
>>
>> The questions are:
>> a) am I missing something?
>> b) do BIOSes (perhaps from other manufacturers) provide the information?
>> c) can we get this fixed?
>
> get updated BIOS.
>
>> d) can we interpolate the information for platforms where the BIOSes
>> don't have the information?
>
> in arch/x86/pci/acpi.c::pci_acpi_scan_root(), we have
>
>        node = -1;
> #ifdef CONFIG_ACPI_NUMA
>        pxm = acpi_get_pxm(device->handle);
>        if (pxm >= 0)
>                node = pxm_to_node(pxm);
>        if (node != -1)
>                set_mp_bus_to_node(busnum, node);
>        else
> #endif
>                node = get_mp_bus_to_node(busnum);
>
>        if (node != -1 && !node_online(node))
>                node = -1;
>
>        info = kzalloc(sizeof(*info), GFP_KERNEL);
>        if (!info) {
>                printk(KERN_WARNING "pci_bus %04x:%02x: "
>                       "ignored (out of memory)\n", domain, busnum);
>                return NULL;
>        }
>
>        sd = &info->sd;
>        sd->domain = domain;
>        sd->node = node;
>
> So kernel will check _PXM at first, or will use pre-probe host bridge info.
> Now we only have that for amd k8 cpu.
>
> We used to have same for intel IOH nehalem,  and get bless from intel.
> but that get removed at some point.
> I have one local internal similar patch for SNB iio for crossing check
> if BIOS set correctly.
> but I don't think i will try to get blessing from intel to publish it.
>
> So please get one updated bios from your vendor.

If ACPI provides a perfectly usable generic way to describe this
topology and the vendor BIOS doesn't bother to use it, I'm not very
interested in trying to compensate for that BIOS deficiency by adding
a bunch of non-portable CPU-specific gunk to Linux.

  parent reply	other threads:[~2012-06-16 21:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAOPLpQfUm-2ENkbnYfXEn1nf9FHnaRk3aqQTSTBWb-CsfCUCFA@mail.gmail.com>
2012-06-16  3:03 ` SNB PCI root information Yinghai Lu
2012-06-16  8:52   ` Thomas Gleixner
2012-06-16 19:36     ` Yinghai Lu
2012-06-16 21:56   ` Bjorn Helgaas [this message]
2012-06-18 22:30     ` Ulrich Drepper
2012-06-18 23:40       ` Yinghai Lu
2012-06-19 12:36         ` Bjorn Helgaas
2012-06-19 18:20           ` Yinghai Lu
2012-06-20 17:11             ` Ulrich Drepper
2012-06-20 17:17             ` Bjorn Helgaas
2012-06-20 17:59               ` Ulrich Drepper
2012-06-20 18:37                 ` Yinghai Lu
2012-06-20 18:46                 ` Bjorn Helgaas
2012-06-20 19:28                   ` Yinghai Lu
2012-06-20 19:34                     ` Ingo Molnar
2012-06-20 20:04                       ` Ulrich Drepper
2012-06-20 20:16                         ` Bjorn Helgaas
2012-06-20 21:21                           ` Ulrich Drepper
2012-06-20 23:58                         ` Yinghai Lu
2012-06-21  2:37                       ` Yinghai Lu
2012-06-21  3:50                         ` Yinghai Lu
2012-06-21 12:17                           ` Ulrich Drepper
2012-06-21 16:22                             ` Ulrich Drepper
2012-06-21 18:11                               ` Yinghai Lu
2012-06-25 17:54                                 ` Ulrich Drepper
2012-06-20 19:57                     ` Brice Goglin
2012-06-21  2:43                       ` Yinghai Lu
2012-06-21  5:56                         ` Brice Goglin
2012-06-21 19:24                           ` Yinghai Lu
2012-06-22  7:14                             ` Brice Goglin
2012-06-22 17:28                               ` Yinghai Lu
2012-06-22 20:38                                 ` Brice Goglin
2012-06-22 20:41                                   ` Yinghai Lu
2012-06-25  9:07                                     ` Brice Goglin

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=CAErSpo57H_ZD_-Z8z9vD3c50My4Rejtc9gXXrxGxDtQomYmrSA@mail.gmail.com \
    --to=bhelgaas@google.com \
    --cc=drepper@gmail.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).