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 20168C369D1 for ; Tue, 22 Apr 2025 20:20:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 765026B0006; Tue, 22 Apr 2025 16:20:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73B6B6B0007; Tue, 22 Apr 2025 16:20:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64FFE6B0008; Tue, 22 Apr 2025 16:20:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 45FEA6B0006 for ; Tue, 22 Apr 2025 16:20:50 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CCC6D68B30 for ; Tue, 22 Apr 2025 20:20:51 +0000 (UTC) X-FDA: 83362798302.01.4A748EB Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id F38A31C000B for ; Tue, 22 Apr 2025 20:20:49 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=cNpG0Nr0; dmarc=none; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745353250; a=rsa-sha256; cv=none; b=awNl4WavqyM7IG7TEag/b95ykdslqnfQMufCjRRA1NJ6FA6MzGuJebohtQ/jeQNI+jFhLq yGyxF2W8LF+HBKX0sZadl2J9gzw1woPmaDQfvLGWvsTcc7z807LlRrN6VD4ws5iLjC/JiV QH07qzj721EpDrYLOEBbmcf38ZiKP7w= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=cNpG0Nr0; dmarc=none; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745353250; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kngkNElZCZ6ITJU2CeQjNiU8OcfD9d1pMU/8LLciI+M=; b=r4KJ6qw5jOT4ouwxxrhJqptFIy9QohF7YSUfXuBVOKphBYfXmuRGkR+oQCsoyAkzVyrdOO wwbN/lQnRc5siccYRbTpuTex+Cu9mYfT3iyNUC3acol+L4/X6BUlyYm/zupoWYdVSHrTUM IAnW8qRZfMkyUvYvZ+IIpayDy8s0ax0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CCD7A5C5DEA; Tue, 22 Apr 2025 20:18:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58FC7C4CEE9; Tue, 22 Apr 2025 20:20:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1745353248; bh=0xhEb/1qj2qQ0bRHlD3fnJYqGYC7qSd5C7GA5eZYVsM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cNpG0Nr00xDGSF3M25gBTnFvtRX49Nbq/fkg7kZKb0jI53bKD8Prfv/EQQeSNSeTB pzTm3cbznEUBJiGNI3+RPrbCSdzSoBIL4Q8PZ6G7d81HatnVu5lcyzyqqC/LOOSny6 nOgXkoUau3bOgMLCoFj/+ZluPcYwjnKv+yAJgJ/k= Date: Tue, 22 Apr 2025 13:20:47 -0700 From: Andrew Morton To: Ruihan Li Cc: Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, David Woodhouse Subject: Re: [PATCH v2] mm/mm_init: Don't iterate pages below ARCH_PFN_OFFSET Message-Id: <20250422132047.22c6cd3a00893bdfd6766df4@linux-foundation.org> In-Reply-To: References: <20250419122801.1752234-1-lrh2000@pku.edu.cn> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: F38A31C000B X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: g5nakck5cqdyt39yq59fprjtbea5hsy8 X-HE-Tag: 1745353249-318147 X-HE-Meta: U2FsdGVkX1+JkECYncuObJRE8k0A3xQ5/93gfDqS0IhqCE9vPK95Zyd3UeMW1AXvD4SL7z7A0jyLPoXGYUclCNG0dtBHmFxRNz0wMHkmqxFPnjauSUpYo16Z+PspaQOESOUpfads7dzk+l/QMZ772U3rY7myVfOwNrfeFV5aXZqPLqgtg1dCII1KbW4PevewWk8s758U2SXNFCTbLmM8gOXbWX1bKlJEj5WcPsXvOkR8vQghTr8UQxuB6QBGkadvU1CUSlG3wMj0v3gfATydtXBlAVZBEafdYU+4LL9Mrr40BitM5Bk06kNlyuLLDhY2tIfmejg9SS+vK7QzPn2oKwYcRU7WHgJbFLBons/R9YTSVCrzTCZ1vpCYi8RL3YEkCYrtkawyQQyCB6EXOcD4IeOBOpMn6CNuYfIadyPoRA+o902qmL9LuMHpzdL8nuWasOe7tijDuq4c/VFAi6f1qxxfQqbP5XuHaj3El4bsVDRqynSWtlDFFBQFvWscJflRKFv+Wbbat4DyC5s1J1wKKVITgh5mYAf94JAbljHZEz1+p+E2jrTwhqPWQ69aC4P8Ivrh/rCRgV66IzPqhypJiqQT94TCKypgntY4PJNLWN7Yyry4IHTejBmGgronlCIUMNjNBAUoXsxeGRyV7GpPwZnDtd7hqo1+Dj0GCVEsGEKxoZwOiMbAjRGNXeuPUDgatY6BPs/XFjMDpNhOHN8nlf2twxQc7V3ybu96Y/NHUKj5ziy2/INuPU99eXsVKydNcnyX1O702LmFRuJqs9ixmdC4mMYXf94WaRNaZGLdpBaT7jdoXIi9R+3wt1Qg2tSdmazpPQlvFw1vuE0q7LJSuSqSZFluIc840IMzqaSy6h+KBG2MywBy4SEI/F0GorvNXsdv3WDRANiZl5zvYzhf+j9ESl+lPxCfWCSFQvi/G3pnePmUo8I+DA059LHtgN5NbiqNiB5Igbs2xZPzFb6 d/bTwni7 e8Evfvl3CKxQDAmoQa2E0vNJQz+u2ato/JEA3OzdY6IqMcBeIkmKNPScROeU9heeYDn88GdX6T47T14esrZhR59OWz17A7QfnSWREnQICXsDqnVeIqapI7YjUWOl0hml4k8rcAidaEMcsXgA+11i7VOSvOQkJyi3Ls/9ivfU15YTW1cYVmBwS/+7xImca+R83OhpG3RsdRELrrbqD7EGh1jvguo6DF1EiFOBoxaLskrre3kSPYDDUhfHyXA+KXVmEB45qH5NW/Oz3O0be38e/otxwCctdh4PUCLuC332T4rUDfHlHsLnbuR1LzM5dQ5sypmfLr62TOsSxZwoOFQzmz1kedYuvqvTw9X0OjjFFWYTYylQHfzVEZXKh+XqLbXJbAOyB 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 Tue, 22 Apr 2025 17:08:06 +0800 Ruihan Li wrote: > Hi Mike, > > Thanks for your review! > > On Mon, Apr 21, 2025 at 07:41:43PM +0300, Mike Rapoport wrote: > > On Sat, Apr 19, 2025 at 08:28:01PM +0800, Ruihan Li wrote: > > > Currently, memmap_init initializes pfn_hole with 0 instead of > > > ARCH_PFN_OFFSET. Then init_unavailable_range will start iterating each > > > page from the page at address zero to the first available page, but it > > > won't do anything for pages below ARCH_PFN_OFFSET because pfn_valid > > > won't pass. > > > > > > If ARCH_PFN_OFFSET is very large (e.g., something like 2^64-2GiB if the > > > kernel is used as a library and loaded at a very high address), the > > > pointless iteration for pages below ARCH_PFN_OFFSET will take a very > > > long time, and the kernel will look stuck at boot time. > > > > > > This commit sets the initial value of pfn_hole to ARCH_PFN_OFFSET, which > > > avoids the problematic and useless iteration mentioned above. > > > > > > This problem has existed since commit 907ec5fca3dc ("mm: zero remaining > > > unavailable struct pages"). > > > > > > Signed-off-by: Ruihan Li > > > --- > > > Link to v1: > > > - https://lore.kernel.org/linux-mm/20250418162727.1535335-1-lrh2000@pku.edu.cn/ > > > Changes since v1: > > > - Removed the unnecessary Fixes tag. > > > - Fixed the build issue for CONFIG_SPARSEMEM. > > > > > > mm/mm_init.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/mm/mm_init.c b/mm/mm_init.c > > > index 84f14fa12..a697a83ff 100644 > > > --- a/mm/mm_init.c > > > +++ b/mm/mm_init.c > > > @@ -969,6 +969,15 @@ static void __init memmap_init(void) > > > unsigned long hole_pfn = 0; > > > int i, j, zone_id = 0, nid; > > > > > > +#ifdef CONFIG_FLATMEM > > > + /* > > > + * Pages below ARCH_PFN_OFFSET are invalid as far as pfn_valid is > > > + * concerned, so don't waste time iterating on them when looking > > > + * for holes. > > > + */ > > > + hole_pfn = ARCH_PFN_OFFSET; > > > +#endif > > > + > > > > I'd prefer a solution for both FLATMEM and SPARSMEM. > > > > David Woodhouse proposed a for_each_valid_pfn() a while ago: > > > > https://lore.kernel.org/all/20250404155959.3442111-1-dwmw2@infradead.org > > > > It can be used in init_unavailable_range() and will essentially skip the > > unpopulated memory map. > > for_each_valid_pfn sounds much better. Thanks for your input. > > However, the problem is that David's patch is not showing up in the > mainline, so what can I do to move forward with my patch? > > Perhaps you mean that I should wait until David's patch is merged and > send another patch to fix the problem? (cc David) > > > > > for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) { > > > struct pglist_data *node = NODE_DATA(nid); > > > > > > -- > > > 2.49.0 > > > > > > > -- > > Sincerely yours, > > Mike. > > Thanks, > Ruihan Li