On Thu, Sep 22, 2016 at 02:49:34PM +1000, David Gibson wrote: > On Wed, Sep 14, 2016 at 07:03:50AM -0500, Michael Roth wrote: > > Quoting Alexey Kardashevskiy (2016-09-14 04:39:10) > > > On 14/09/16 09:29, Michael Roth wrote: > > > > Quoting Alexey Kardashevskiy (2016-07-27 03:03:38) > > > >> This adds a numa id property to a PHB to allow linking passed PCI > > > >> device > > > >> to CPU/memory. It is up to the management stack to do CPU/memory > > > >> pinning > > > >> to the node with the actual PCI device. > > > > > > > > It looks like x86 relies on PCIBus->numa_node() method (via > > > > pci_bus_numa_node()) to encode similar PCIBus affinities > > > > into ACPI tables, and currently exposes it via > > > > -device pci-[-express]-expander-bus,numa_node=X. > > > > > > > > > > > > Well, until we allow DMA windows per PCI bus (not per PHB as it is now), > > > this won't make much sense for us (unless I am missing something here). > > > > I didn't consider that it's not a bus-level setting; I think > > you're right that re-using the interface to both store/retrieve doesn't > > make much sense in that case. > > > > My thought that was that since pci_bus_numa_node() could in theory come > > to be relied upon by common PCI code, that we should use it as well. But > > even if it doesn't make sense for us to use it, wouldn't it make sense to > > still set PCIBus->numa_node (in addition to the PHB-wide value) in the > > off-chance that common code does come to rely on > > pci_bus_numa_node()? > > Yes, it would be a good idea to set the PCIBus node value to inherit > the one that's set for the host bridge, just in case any generic code > looks at it in future.
But that can be a followup patch, I've applied this to ppc-for-2.8
now.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
