Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1773622imm; Thu, 9 Aug 2018 01:32:53 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzmAJNXXevYqErsx2GhkHPXi0rp9IgV6u4r2AvAGhIGT3ncCDBKMylpw+JIvh/rlULus1YP X-Received: by 2002:a62:fd06:: with SMTP id p6-v6mr1311506pfh.167.1533803573791; Thu, 09 Aug 2018 01:32:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533803573; cv=none; d=google.com; s=arc-20160816; b=pMcyN2NRWfCOrAvJxeQihzgkmmo3Fvme8R7y0hr7UGXtyt7V8CLYcCSL9gm5J8lEzH AjeGTDk8DzjV0LUcKDD/WBHyATVYNijqW5XuB15rzMeq3qKanAiqsJpsFcEjVeVGgWJ6 p9g1DYrv9/qAz6oujtQjm8oGGQdwQktXfFQdbL9LLbKwFBwgXrWKUvn172+a7NM3HwVs 7YhtEwIykHqC+2fGnoPmHRxwBEK+c7TY5X2eX+LD4bKUiotDQkPmNyiwe/jqa57Eosap Gb4u+PDagUkNtgYj80yOQNxt2mgEdk2KN2iqzTTR05eDbxsjlCPw8yvyVGOPT6Cd5xff HVhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=n/whmiw03Yj7863DNhau5SBQYI1tCSGO8FbyGV2nEcM=; b=wm2fwd0mp4y48mBYNXcWWYznhUADMLUjdTIERhHmbhcTjVR4V/Xsw6YYeQm9zg+yBV sqIyVYqBjD4TNur+CGlOEp80FJacXCNW2fY7B1xzgjz6DbaaS3PtDtQPX/bd7Sfeb4U9 kGe4AeY7up2EEA3j+W4UaJSW+xrjzHjOe4lhtK81F3ziKlaHcrV5wWb6Cpo6UZc+c5UQ EhjMU6McU7t3g1h22FR+tNYEQDXsTRLE76ikpBP6FhHGLd4QG7rRZ370LEOc8R/h8JAw qzo5OEZ6t5S95I/gYDIfK2JYjiCsyLILddjWcj88E1Vv5uo8p8l+4jp7Un2ULrpOn5sI 50sw== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o126-v6si6689670pfb.20.2018.08.09.01.32.39; Thu, 09 Aug 2018 01:32:53 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730009AbeHIKz3 (ORCPT + 99 others); Thu, 9 Aug 2018 06:55:29 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:50102 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728170AbeHIKz3 (ORCPT ); Thu, 9 Aug 2018 06:55:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BA13918A; Thu, 9 Aug 2018 01:31:43 -0700 (PDT) Received: from localhost (e105922-lin.Emea.Arm.com [10.4.13.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5E0E93F5D0; Thu, 9 Aug 2018 01:31:43 -0700 (PDT) From: Punit Agrawal To: Bjorn Helgaas 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 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> <20180808172211.GD49411@bhelgaas-glaptop.roam.corp.google.com> Date: Thu, 09 Aug 2018 09:31:41 +0100 In-Reply-To: <20180808172211.GD49411@bhelgaas-glaptop.roam.corp.google.com> (Bjorn Helgaas's message of "Wed, 8 Aug 2018 12:22:11 -0500") Message-ID: <871sb83pqq.fsf@e105922-lin.cambridge.arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bjorn Helgaas writes: > 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(). Thanks for confirming. I'm happy to add a patch updating x86 use of kzalloc_node() as well. I'll post something once the merge window closes. > > Bjorn