From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C5F94C3DA4A for ; Mon, 5 Aug 2024 20:36:47 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=g0ifEE+/; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Wd7Wy3nnrz3cgd for ; Tue, 6 Aug 2024 06:36:46 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=g0ifEE+/; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=145.40.73.55; helo=sin.source.kernel.org; envelope-from=rppt@kernel.org; receiver=lists.ozlabs.org) Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Wd7W66l4Kz30Sv for ; Tue, 6 Aug 2024 06:36:02 +1000 (AEST) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id CBB4BCE0B42; Mon, 5 Aug 2024 20:35:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A51B2C32782; Mon, 5 Aug 2024 20:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722890158; bh=wRagKm6MS39NDYLBbcdNfb/zxQJOwJqmtNN36cxhWNE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g0ifEE+/fQd9VQyFJiGF6eqG5LkKWn0QoytIRLG6RGNO3Qz+ixAqBqBhJXWXYzJE8 0lFaNo21LgP2mbO565lm6BtVRnS7fXNHEJVy8zEtHsy8Uw8u/a5v19B4OkrZVUS3fx ix+vSxthkk0vtjORnJgV3NWtYxBAy3BhlS8nwLVfIFfPyq5ww4vSd2FHKgUzoj06Iv Vb4ByzZFa5e2puJlKIa3k2+AazNy3wMipT1Qok9eH8nBZ24hNYG5OjUnktHHi7xdO4 HdW3CuSUf4iLi1uAYROJiEHzYtewSLvIDZn8z4DY92o6CWtrXY1hYgkOWg3WUTpR8E O3fqMHFNWnE8A== Date: Mon, 5 Aug 2024 23:33:39 +0300 From: Mike Rapoport To: Dan Williams Subject: Re: [PATCH v3 22/26] mm: numa_memblks: use memblock_{start,end}_of_DRAM() when sanitizing meminfo Message-ID: References: <20240801060826.559858-1-rppt@kernel.org> <20240801060826.559858-23-rppt@kernel.org> <66b1342e8af7f_c1448294af@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66b1342e8af7f_c1448294af@dwillia2-xfh.jf.intel.com.notmuch> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: nvdimm@lists.linux.dev, x86@kernel.org, Andreas Larsson , Catalin Marinas , Dave Hansen , David Hildenbrand , Jiaxun Yang , linux-mips@vger.kernel.org, linux-mm@kvack.org, sparclinux@vger.kernel.org, Alexander Gordeev , Will Deacon , linux-riscv@lists.infradead.org, linux-arch@vger.kernel.org, Rob Herring , Davidlohr Bueso , Vasily Gorbik , Jonathan Corbet , linux-sh@vger.kernel.org, Huacai Chen , Christophe Leroy , linux-acpi@vger.kernel.org, Ingo Molnar , Zi Yan , devicetree@vger.kernel.org, Arnd Bergmann , linux-s390@vger.kernel.org, Heiko Carstens , Borislav Petkov , linux-cxl@vger.kernel.org, loongarch@lists.linux.dev, John Paul Adrian Glaubitz , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Thomas Bogendoerfer , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Samuel Holland , Palmer Dabbelt , Jonathan Cameron , "Rafael J. Wysocki" , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Aug 05, 2024 at 01:21:02PM -0700, Dan Williams wrote: > Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" > > > > numa_cleanup_meminfo() moves blocks outside system RAM to > > numa_reserved_meminfo and it uses 0 and PFN_PHYS(max_pfn) to determine > > the memory boundaries. > > > > Replace the memory range boundaries with more portable > > memblock_start_of_DRAM() and memblock_end_of_DRAM(). > > Can you say a bit more about why this is more portable? Is there any > scenario for which (0, max_pfn) does the wrong thing? arm64 may have DRAM starting at addresses other than 0. And max_pfn seems to me a redundant global variable that I'd love to see gone. -- Sincerely yours, Mike.