From patchwork Wed Aug 7 06:40:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 13755769 X-Patchwork-Delegate: iweiny@gmail.com Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5276D1B86F9; Wed, 7 Aug 2024 06:43:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723013013; cv=none; b=Web04NiwawAaHPZL4RzjNhNiyZAOfSqo8uAAdvLLYmBavhVM2ZkGlMKgSzpBs738BNC6M/LeaLja4dB1nja44iNe7H8PpYClq/ZDCHUypbv+aVToJXXGYj8L4dBcf1I2jiNj0pgwHyPhWOa5o/hDriKZdyHfWBpx1HKqzdNW4Lo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723013013; c=relaxed/simple; bh=oI0PgIj2KycFldDjpn7t4up1B9CyY8k+mV9pmYYqhIc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Zay1R3ZIMfv5WSnlm5Cq2Grwc/csQbpJDGfiPHMA8dCpiF7CwG4d/BMmTQIZ132JteCPWnuxNyKCdv6s6xHcluRSZPI1kYFj2G7PfJFYjUFOIcz7KyaJKf1RxnOdqipEqS9eljtmhGwJZvBFf+Nyesgv1RjiR7kR5/gn4Nj54kI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MwQbjBVK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MwQbjBVK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90229C32782; Wed, 7 Aug 2024 06:43:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723013011; bh=oI0PgIj2KycFldDjpn7t4up1B9CyY8k+mV9pmYYqhIc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MwQbjBVKjQqb4wvlUKk+TvUzuSfMVWniCHu/HcU7BSTWqSXo3UJM+bVzPh8FcFdBv DeWCt2T4+0qdL3hz9ZqqW0dE9SlBcxOVVmyabru0iOG0hiJtyM79loZFzgQu3qtlbF KZym6bNAkjulkyU4p59qFVDEB+pr4p26qJiPpd4RrPwnjO81rPE1gcFUvs52RA7xwX cAR47FIRG3ACzj84LkbB2Pg0I15b0pRDvImCww1cL/G+YFJmmgyNLKFRPtoHZ1OsRg Xkr1cXHPofbicNDYDN0/AGjV8FFB0naD0WJzlbdduxBKy3u7qdN/nSDGtG3ua8xHE8 azsdImVG7Eu1g== From: Mike Rapoport To: linux-kernel@vger.kernel.org Cc: Alexander Gordeev , Andreas Larsson , Andrew Morton , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christophe Leroy , Dan Williams , Dave Hansen , David Hildenbrand , "David S. Miller" , Davidlohr Bueso , Greg Kroah-Hartman , Heiko Carstens , Huacai Chen , Ingo Molnar , Jiaxun Yang , John Paul Adrian Glaubitz , Jonathan Cameron , Jonathan Corbet , Michael Ellerman , Mike Rapoport , Palmer Dabbelt , "Rafael J. Wysocki" , Rob Herring , Samuel Holland , Thomas Bogendoerfer , Thomas Gleixner , Vasily Gorbik , Will Deacon , Zi Yan , devicetree@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-cxl@vger.kernel.org, linux-doc@vger.kernel.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, nvdimm@lists.linux.dev, sparclinux@vger.kernel.org, x86@kernel.org, Jonathan Cameron Subject: [PATCH v4 10/26] x86/numa: simplify numa_distance allocation Date: Wed, 7 Aug 2024 09:40:54 +0300 Message-ID: <20240807064110.1003856-11-rppt@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240807064110.1003856-1-rppt@kernel.org> References: <20240807064110.1003856-1-rppt@kernel.org> Precedence: bulk X-Mailing-List: nvdimm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "Mike Rapoport (Microsoft)" Allocation of numa_distance uses memblock_phys_alloc_range() to limit allocation to be below the last mapped page. But NUMA initializaition runs after the direct map is populated and there is also code in setup_arch() that adjusts memblock limit to reflect how much memory is already mapped in the direct map. Simplify the allocation of numa_distance and use plain memblock_alloc(). Signed-off-by: Mike Rapoport (Microsoft) Tested-by: Zi Yan # for x86_64 and arm64 Reviewed-by: Jonathan Cameron Tested-by: Jonathan Cameron [arm64 + CXL via QEMU] Acked-by: Dan Williams Acked-by: David Hildenbrand --- arch/x86/mm/numa.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c index 5e1dde26674b..edfc38803779 100644 --- a/arch/x86/mm/numa.c +++ b/arch/x86/mm/numa.c @@ -331,7 +331,6 @@ static int __init numa_alloc_distance(void) nodemask_t nodes_parsed; size_t size; int i, j, cnt = 0; - u64 phys; /* size the new table and allocate it */ nodes_parsed = numa_nodes_parsed; @@ -342,16 +341,14 @@ static int __init numa_alloc_distance(void) cnt++; size = cnt * cnt * sizeof(numa_distance[0]); - phys = memblock_phys_alloc_range(size, PAGE_SIZE, 0, - PFN_PHYS(max_pfn_mapped)); - if (!phys) { + numa_distance = memblock_alloc(size, PAGE_SIZE); + if (!numa_distance) { pr_warn("Warning: can't allocate distance table!\n"); /* don't retry until explicitly reset */ numa_distance = (void *)1LU; return -ENOMEM; } - numa_distance = __va(phys); numa_distance_cnt = cnt; /* fill with the default distances */