From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pci: derive nearby CPUs from device's instead of bus' NUMA information
Date: Thu, 7 May 2009 10:51:36 +0200 [thread overview]
Message-ID: <20090507085136.GC2868@alberich.amd.com> (raw)
In-Reply-To: <20090420130341.098c8ebe@hobbes>
On Mon, Apr 20, 2009 at 01:03:41PM -0700, Jesse Barnes wrote:
> On Mon, 20 Apr 2009 10:47:47 +0200
> Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
>
> > On Fri, Apr 17, 2009 at 12:26:54PM -0700, Yinghai Lu wrote:
> > > On Fri, Apr 17, 2009 at 9:21 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > > > const struct cpumask * cpumask_of_pcidev(struct pci_dev *dev)
> > > > {
> > > > if (dev->numa_node == -1)
> > > > return cpumask_of_pcibus(to_pci_dev(dev)->bus);
> > > >
> > > > return cpumask_of_node(dev_to_node(dev));
> > > > }
> > > >
> > > > ? This would work fine in all cases.
> >
> > Yes, I think so. That's the general solution w/o additional
> > "ifdefing".
> >
> > > you are right, dev_to_node(dev) could return -1 on 64bit, if there
> > > is no memory on that node.
> >
> > Hmm, I thought just in the CONFIG_NUMA=n case -1 is returned.
> >
> > During initialization the struct device's numa_node is set to -1 and
> > later on the information is inherited from the parent numa_node.
> >
> > So what do I miss?
>
> I like the idea of cpumask_of_pcidev(), but it seems like
> cpumask_of_pcibus should return the same value. So if the node is
> unassigned or "equadistant" (there's code that treats -1 as both I
> think), cpumask_of_pcibus should figure out what the nearest CPUs are
> and return that, right?
Usually this is true.
But there is one special case.
Northbridge functions of AMD CPUs appear to be on bus 0 device 24-31
(each having 4 or 5 functions depending on the CPU family).
Requests to those devices (e.g. reading config space) are handled by
the processor(s) themselves and aren't routed to the PCI bus.
At most such requests are routed to another processor (node) if the
request is for a northbridge function of a different processor.
See 9b94b3a19b13e094c10f65f24bc358f6ffe4eacd for some additional info.
That is why I think that using cpumask_of_pcidev should have
precedence over cpumask_of_pcibus. (numa_node information of a PCI
device can be fixed up and then differ from node information of the
PCI bus .)
Regards,
Andreas
--
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
next prev parent reply other threads:[~2009-05-07 8:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 10:01 [PATCH] pci: derive nearby CPUs from device's instead of bus' NUMA information Andreas Herrmann
2009-04-17 16:21 ` Ingo Molnar
2009-04-17 19:26 ` Yinghai Lu
2009-04-20 8:47 ` Andreas Herrmann
2009-04-20 20:03 ` Jesse Barnes
2009-05-07 8:51 ` Andreas Herrmann [this message]
2009-05-11 21:54 ` Jesse Barnes
2009-06-09 5:47 ` Andreas Herrmann
2009-04-20 21:23 ` Yinghai Lu
2009-04-21 18:05 ` Andreas Herrmann
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=20090507085136.GC2868@alberich.amd.com \
--to=andreas.herrmann3@amd.com \
--cc=hpa@zytor.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=yhlu.kernel@gmail.com \
/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