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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4EA8BC3DA7F for ; Mon, 5 Aug 2024 20:37:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D96DD6B0088; Mon, 5 Aug 2024 16:37:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D47866B0089; Mon, 5 Aug 2024 16:37:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0E4B6B008C; Mon, 5 Aug 2024 16:37:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 9E4716B0088 for ; Mon, 5 Aug 2024 16:37:44 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5105480484 for ; Mon, 5 Aug 2024 20:37:44 +0000 (UTC) X-FDA: 82419352848.20.6C8A088 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 9E47E1C000D for ; Mon, 5 Aug 2024 20:37:42 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bF0xgt41; spf=pass (imf21.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722890232; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8j+MdJnW944luPG1S/D/pTiCdg4zoiFDwrc37UyH3r8=; b=gToK4G0vdvRX7HCtRdb++nJ5dxtVF00RFUDQg9R/rG5UOzQxvCySpcGm3Phd4/rv81Tlwq qia3SXZn24bKe22CFF1jhifWWruYCWhLGJGitGGk4wTxKaIJp5zWPBRzRpt5lRxOOAEM1x j5calpOsIOsV+CaC+jpIcbz2nP1u9G8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bF0xgt41; spf=pass (imf21.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722890232; a=rsa-sha256; cv=none; b=pAF11u9q3k25ilL5P6cCZ8V8LbezhuPYm4Ebw22U9TQY6Sdvu2RMhEiLJXaEZxTK5GqTps UQUymPV6V5r8ALk1vn6lgaISB8qvJZhtWAechRdeRLsVPb+ShK7VY3VMVii3p8yiWVIzPW 4WSLVpe8KTv9swPeUGtf865QR1//Xp8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id AD1AD60DD2; Mon, 5 Aug 2024 20:37:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 087EBC4AF0E; Mon, 5 Aug 2024 20:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722890261; bh=qdRuOti9XNlLltkR78ltAp8iub7ZiaEGkve5ZQKgRXs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bF0xgt419GbxyCGFRj0fNjByi1OtMInAxUy0fO7kuEExoo6r6jeZMXGjN5ikPGLYH /M1nzHizackmgautp/VnDSLRxQXCurMyrYVEwg5Yf+PdgGkwhSt7ZiA1a6tEsPe3+w oJPfE55fHB91q50vVv1vV9hAXYemhAyhr6OpNgWOOvXUx9/9Vw4S7evidbf87YcNj+ pEPIiDW05PYUn8lRlujrJ1DKbY3WIHytjXuNelSTWpy7nXBiYR1lO2v9ZQh4g3aHrR PgFXkbijAdUJ0BywpuS1YJGB4AvPiLFgG1t0OrXdtLJEh5IFQJb88z75ZKH8cfv8oU ALk7ATW/rOneA== Date: Mon, 5 Aug 2024 23:35:22 +0300 From: Mike Rapoport To: Dan Williams Cc: linux-kernel@vger.kernel.org, Alexander Gordeev , Andreas Larsson , Andrew Morton , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christophe Leroy , 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 , 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 Subject: Re: [PATCH v3 11/26] x86/numa: use get_pfn_range_for_nid to verify that node spans memory Message-ID: References: <20240801060826.559858-1-rppt@kernel.org> <20240801060826.559858-12-rppt@kernel.org> <66b1302ce5fd3_c1448294d3@dwillia2-xfh.jf.intel.com.notmuch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66b1302ce5fd3_c1448294d3@dwillia2-xfh.jf.intel.com.notmuch> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 9E47E1C000D X-Stat-Signature: fmn35grj8xgs4prgct6trp57gwgcentz X-HE-Tag: 1722890262-763696 X-HE-Meta: U2FsdGVkX18/mQUegtPHmACn5vQZRnq4CMiz1WBYuvtlKtC0IYpWsVXmyPeX12cfMSTYRQtdAirMhMlmWBnqrV0aUHpJByKljnCgODuGG1lY8LgNvuWCSOrzTHzNUdFsejU/fhUM7TC422Iv5KoYEMiLHtdatYv+ITkRwQChspcA7ncMZ/FbPlr2cZTPJZeZCLqeXv3hnUqlFZJVoPg0C5Fr8/NabnSVpm1IKy19qYJWCzC86SRS9/fLBdcnUc3PiEfMhNJGL24ZXkqanTC3sbRbHjyCBwjV6ZQ3lC2+j4n68S/9Py2ZBYaIQu7tIfW7vYPDcJfxoj8HQs+8kV5X6vfEqhxrKW+waYw5kduDjpo3UGC3dmGrTVC3/eg5QGZW3gh/SFwSKRl+QxYV/O7frQglwSNKbwvXQwypx2Th1RxnSwcdVkVgsmri7ri14VLmgHZKZDVbNWIZ4y0tNSweyBZHVT8vLWwr0Y38NbjwCKb1pOKaNxLwnP2HmhYmzQROv99h4U7/2ittYUP0NWHCSaJfrOwgIb4o1l20Hnr7zhZJNeNXYsJHE6XrZbwjFSQx0YCbFv7YeUJVhHxWrobkX359Gn12fhh2rc1w+HQEuACoPVFjmVlgth7KMVo28QPn8FfEhtZ/mcUzsp8B4Kst7QREHTsXOMotcnCgIZCdErPh+xqyq6zmpCJyUvYoHABLjTM85NndS7oOB9gCqDaZBPPfBiodJ0+N4Q0K0wptZPRLOKBzZ6SQnJjrWKqaIkGgEw6Qm2t8M9Fz2DQYQuny6yg1DR7dvUCQ62Q4p1QfsVZ+xj0xKApYqfNZdHA2qKwS7YGjpipb/vKfxZ5zILQOWddotNDKkUd5v1DDXwpMPFsDnf6qKTCvLHEN1ZBKO9tmWhxEGqM1m5gITvgW0/j0l0cjzaT35BqOZKTJLMv2eNglv4hgT5ItV7ek3WlWT/bSaZ5ccaTsXZeEfLUic/r 0fJTbvrg ECvzfdmEJib36lhyHbQP5R/oF6nGNn663CMfFd9XVrpHQi3W98HnApWw//pLZzP3tKmqloli34/PArfAzj7KeR7xHXgOniyA8/dSaHer6Fb/TXCS6nthm3YPk4gRvHRpnNUEChGVUuOED7N1ssQdI1LthvFfXMeQ9pOq+YiguIajL/ryh7HNU9w7HWSUQiOPsK4niYBZqmi6RnTnCDg9/YZE5EqHovwCIo00iCeGvvZ9YfrimL/zJWr+WNmsudXuxMS3TjMUHVD9EUsa9TmjJLQLmoSsw0T1TcJZItLCUs5N4of75E3G7pIU52XY2L5NCfrmJhsoE0QeVauOoh/drt73s3zc6pk5MZL8J6bOWlHp81kWK04Fq0Y/2EDvgDg9ZAJVmQM6xOYd7yWo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Aug 05, 2024 at 01:03:56PM -0700, Dan Williams wrote: > Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" > > > > Instead of looping over numa_meminfo array to detect node's start and > > end addresses use get_pfn_range_for_init(). > > > > This is shorter and make it easier to lift numa_memblks to generic code. > > > > Signed-off-by: Mike Rapoport (Microsoft) > > Tested-by: Zi Yan # for x86_64 and arm64 > > --- > > arch/x86/mm/numa.c | 13 +++---------- > > 1 file changed, 3 insertions(+), 10 deletions(-) > > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > > index edfc38803779..cfe7e5477cf8 100644 > > --- a/arch/x86/mm/numa.c > > +++ b/arch/x86/mm/numa.c > > @@ -521,17 +521,10 @@ static int __init numa_register_memblks(struct numa_meminfo *mi) > > > > /* Finally register nodes. */ > > for_each_node_mask(nid, node_possible_map) { > > - u64 start = PFN_PHYS(max_pfn); > > - u64 end = 0; > > + unsigned long start_pfn, end_pfn; > > > > - for (i = 0; i < mi->nr_blks; i++) { > > - if (nid != mi->blk[i].nid) > > - continue; > > - start = min(mi->blk[i].start, start); > > - end = max(mi->blk[i].end, end); > > - } > > - > > - if (start >= end) > > + get_pfn_range_for_nid(nid, &start_pfn, &end_pfn); > > + if (start_pfn >= end_pfn) > > Assuming I understand why this works, would it be worth a comment like: > > "Note, get_pfn_range_for_nid() depends on memblock_set_node() having > already happened" Will add a comment, sure. > ...at least that context was not part of the diff so took me second to > figure out how this works. > -- Sincerely yours, Mike.