[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090901100951.6bf5f7e0@jbarnes-g45>
Date: Tue, 1 Sep 2009 10:09:51 -0700
From: Jesse Barnes <jbarnes@...tuousgeek.org>
To: Yinghai Lu <yinghai@...nel.org>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Jesse Brandeburg <jesse.brandeburg@...il.com>
Subject: Re: [PATCH] x86/PCI: initialize PCI bus node numbers early
On Tue, 01 Sep 2009 09:55:34 -0700
Yinghai Lu <yinghai@...nel.org> wrote:
> Ingo Molnar wrote:
> > * Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> >
> >> The current mp_bus_to_node array is initialized only by AMD
> >> specific code, since AMD platforms have registers that can be used
> >> for determining mode numbers. On new Intel platforms it's
> >> necessary to initialize this array as well though, otherwise all
> >> PCI node numbers will be 0, when in fact they should be -1
> >> (indicating that I/O isn't tied to any particular node).
> >>
> >> So move the mp_bus_to_node code into the common PCI code, and
> >> initialize it early with a default value of -1. This may be
> >> overridden later by arch code (e.g. the AMD code).
> >>
> >> With this change, PCI consistent memory and other node specific
> >> allocations (e.g. skbuff allocs) should occur on the "current"
> >> node. If, for performance reasons, applications want to be bound
> >> to specific nodes, they should open their devices only after being
> >> pinned to the CPU where they'll run, for maximum locality.
> >>
> >> Any thoughts here Yinghai or Jesse?
> >>
> >>
> >> include/asm/pci.h | 2 +
> >> kernel/setup.c | 2 +
> >> pci/amd_bus.c | 61
> >> +----------------------------------------- pci/common.c |
> >> 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files
> >> changed, 83 insertions(+), 59 deletions(-)
> >
> > FYI, this commit:
> >
> > acccaba: x86/PCI: initialize PCI bus node numbers early
> >
> > caused a boot crash in -tip testing:
> >
>
> looks like the patch change default 0 in 32bit to -1 ...
Yeah, that's the idea. We want the node to be "don't care" on
platforms that don't have a specific bridge to node mapping. Not sure
why it fails in the mrst tree though..
Looks like we're taking an amd specific path in the backtrace, maybe
with the reshuffling of things we're calling one of the amd routines
before the real node numbers have been set up and they can't handle -1?
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists