From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: PCI: Remove node-local allocations when initialising host controller
Date: Thu, 2 Aug 2018 15:33:19 +0100 [thread overview]
Message-ID: <20180802143319.GA13512@red-moon> (raw)
In-Reply-To: <38ad03ba-2658-98c8-1888-0aa3bfb59bd4@arm.com>
On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wrote:
> Hi,
>
> +CC Jiang Lui
Jiang Liu does not work on the kernel anymore so we won't know
anytime soon the reasoning behind commit 965cd0e4a5e5
> On 08/01/2018 12:31 PM, Punit Agrawal wrote:
> >Memory for host controller data structures is allocated local to the
> >node to which the controller is associated with. This has been the
> >behaviour since support for ACPI was added in
> >commit 0cb0786bac15 ("ARM64: PCI: Support ACPI-based PCI host controller").
>
> Which was apparently influenced by:
>
> 965cd0e4a5e5 x86, PCI, ACPI: Use kmalloc_node() to optimize for performance
>
> Was there an actual use-case behind that change?
>
> I think this fixes the immediate boot problem, but if there is any
> perf advantage it seems wise to keep it... Particularly since x86
> seems to be doing the node sanitation in pci_acpi_root_get_node().
I am struggling to see the perf advantage of allocating a struct
that the PCI controller will never read/write from a NUMA node that
is local to the PCI controller, happy to be corrected if there is
a sound rationale behind that.
Lorenzo
>
>
>
> >
> >Drop the node local allocation as there is no benefit from doing so -
> >the usage of these structures is independent from where the controller
> >is located. It also causes problem during probe if the associated numa
> >node hasn't been initialised due to booting with restricted cpus via
> >kernel command line or where the node doesn't have cpus or memory
> >associated with it.
> >
> >Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> >Cc: Catalin Marinas <catalin.marinas@arm.com>
> >Cc: Will Deacon <will.deacon@arm.com>
> >Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >---
> >Hi,
> >
> >This came up in the context of investigating the boot issues reported
> >due to restricted cpus or buggy firmware. Part of the problem is fixed
> >by Lorenzo's rework of NUMA initialisation[0].
> >
> >But there also doesn't seem to be any justification for using
> >node-local allocation to begin with.
> >
> >Thanks,
> >Punit
> >
> >[0] https://patchwork.kernel.org/patch/10486001/
> >
> > arch/arm64/kernel/pci.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> >diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> >index 0e2ea1c78542..bb85e2f4603f 100644
> >--- a/arch/arm64/kernel/pci.c
> >+++ b/arch/arm64/kernel/pci.c
> >@@ -165,16 +165,15 @@ static void pci_acpi_generic_release_info(struct acpi_pci_root_info *ci)
> > /* Interface called from ACPI code to setup PCI host controller */
> > struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> > {
> >- int node = acpi_get_node(root->device->handle);
> > struct acpi_pci_generic_root_info *ri;
> > struct pci_bus *bus, *child;
> > struct acpi_pci_root_ops *root_ops;
> >- ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
> >+ ri = kzalloc(sizeof(*ri), GFP_KERNEL);
> > if (!ri)
> > return NULL;
> >- root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
> >+ root_ops = kzalloc(sizeof(*root_ops), GFP_KERNEL);
> > if (!root_ops) {
> > kfree(ri);
> > return NULL;
> >
>
next prev parent reply other threads:[~2018-08-02 14:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-01 17:31 [PATCH] arm64: PCI: Remove node-local allocations when initialising host controller Punit Agrawal
2018-08-01 19:38 ` Jeremy Linton
2018-08-02 14:33 ` Lorenzo Pieralisi [this message]
2018-08-08 13:54 ` Bjorn Helgaas
2018-08-08 14:44 ` Punit Agrawal
2018-08-08 17:22 ` Bjorn Helgaas
2018-08-09 8:31 ` Punit Agrawal
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=20180802143319.GA13512@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=linux-arm-kernel@lists.infradead.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