Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1081524imm; Wed, 8 Aug 2018 10:23:57 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwN96sXrTqr6iLG8d2i2/ifFs3yyEbplx4lQXxC6TiNTR0z+GZWzV5I5ZhUHRis60yoylfr X-Received: by 2002:a63:4951:: with SMTP id y17-v6mr3496143pgk.32.1533749037591; Wed, 08 Aug 2018 10:23:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533749037; cv=none; d=google.com; s=arc-20160816; b=f9TupRb83UPrGCMxtIZE6/qdoUOxa37nb0ij/EWLZyMiVDyOcSKYFSbVSa+lPQ+m93 ezZwBKOfem55w0b59atMOAOW38js+RdgG2AtexvFM1psBSMQTAete3a4slaafxPOgiCe QF1hMOUE99GcVmgMJzIrlN1kw6mwcm5+nmvk0V1HUF7tIR6uUOepD3F4dneii8SMcolg eo/jmNnilwakuVaxLfw+Tb7YJie47XUlAqAenMx2ucOq3WZonB/l0SvkbsbEbf45bRLi BfXjZtiImf0cp7PVIjfJUIZXfZ5RBXx9h80F8aZF5SemLzHU3lUvDQUUAS1E/Q8HDomm j4WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=gCRKGhzgW2r0A1jywfK1iX51EfenFxG0g1sDzeaCCIA=; b=RgBKdTrqJucYqwlp4+HTETArWWHX8qYjlJHgGa0RifmYWU+iQo6R5I5Czsj8AC9rFb +W6e1tm3/k9IVFq1fQoxqvObqy1/PFwUJlCGAWZzF794nnC+1mo6BchGp3khZAHFONFS iGgan3slb8JnlZeyFperwsdCMoEd2O5blAqDl3lr36V1thFzSRJNSftjWEPF5ev8dgqw E+wIJqZTfJ0+CYBRaZ5jrMG6ZagwzR54sIxuokSYdryvdBkgdVKHoHPJaNZoHoctRXy1 cSJ4B9xFtkLWOjtyUudP2tb8GpPPGOo9hb81U1rq7KcFUxQAPEx8ZpmrE61xxJQ41285 vm6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Z56Aywdg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9-v6si4159273pga.456.2018.08.08.10.23.42; Wed, 08 Aug 2018 10:23:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Z56Aywdg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728711AbeHHTmx (ORCPT + 99 others); Wed, 8 Aug 2018 15:42:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:34288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727295AbeHHTmx (ORCPT ); Wed, 8 Aug 2018 15:42:53 -0400 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C07CC216F4; Wed, 8 Aug 2018 17:22:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1533748934; bh=WbFLpkB48cWNNVo4a6UbymRHF8em7Fk2LnPG1R/+ya8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z56Aywdgc80wK8xLDOSSOwpj58RfC6lqkxt/jxtVGw0Szalv654+DCJbd3nCXZzz1 8LDqb+273onexzn5S5LHp2fROgWqY/81F7aWtbzTiEn0NRjlBiVwH6DqFp8qt9ZOG1 ALaDMZCfPI6Qb/Z41/afiMigpXxAdDbsrEUPgM/s= Date: Wed, 8 Aug 2018 12:22:11 -0500 From: Bjorn Helgaas To: Punit Agrawal Cc: Bjorn Helgaas , Lorenzo Pieralisi , Jeremy Linton , linux-arm , Catalin Marinas , Will Deacon , Jiang Liu , linux-pci@vger.kernel.org, Linux Kernel Mailing List , linux-acpi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] arm64: PCI: Remove node-local allocations when initialising host controller Message-ID: <20180808172211.GD49411@bhelgaas-glaptop.roam.corp.google.com> References: <20180801173132.19739-1-punit.agrawal@arm.com> <38ad03ba-2658-98c8-1888-0aa3bfb59bd4@arm.com> <20180802143319.GA13512@red-moon> <87eff85364.fsf@e105922-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eff85364.fsf@e105922-lin.cambridge.arm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 08, 2018 at 03:44:03PM +0100, Punit Agrawal wrote: > Bjorn Helgaas writes: > > On Thu, Aug 2, 2018 at 9:33 AM Lorenzo Pieralisi > > wrote: > >> On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wrote: > >> > >> 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. > > > > If there is no reason to use kzalloc_node() here, we shouldn't use it. > > > > But we should use it (or not use it) consistently across arches. I do > > not believe there is an arch-specific reason to be different. > > Currently, pci_acpi_scan_root() uses kzalloc_node() on x86 and arm64, > > but kzalloc() on ia64. They all ought to be the same. > > From my understanding, arm64 use of kzalloc_node() was derived from the > x86 version. Maybe somebody familiar with behaviour on x86 can provide > input here. If you want to remove use of kzalloc_node(), I'm fine with that as long as you do it for x86 at the same time (maybe separate patches, but at least in the same series). I don't see any evidence in 965cd0e4a5e5 ("x86, PCI, ACPI: Use kmalloc_node() to optimize for performance") that it actually improves performance, so I'd be inclined to just use kzalloc(). Bjorn