From: Mike Rapoport <rppt@kernel.org>
To: Ruihan Li <lrh2000@pku.edu.cn>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/mm_init: Don't iterate pages below ARCH_PFN_OFFSET
Date: Mon, 21 Apr 2025 19:41:43 +0300 [thread overview]
Message-ID: <aAZ1RzQdgllQYM04@kernel.org> (raw)
In-Reply-To: <20250419122801.1752234-1-lrh2000@pku.edu.cn>
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 <lrh2000@pku.edu.cn>
> ---
> 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_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) {
> struct pglist_data *node = NODE_DATA(nid);
>
> --
> 2.49.0
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-04-21 16:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-19 12:28 [PATCH v2] mm/mm_init: Don't iterate pages below ARCH_PFN_OFFSET Ruihan Li
2025-04-20 20:57 ` Andrew Morton
2025-04-21 9:35 ` Ruihan Li
2025-04-21 16:35 ` Mike Rapoport
2025-04-21 18:26 ` Andrew Morton
2025-04-21 16:41 ` Mike Rapoport [this message]
2025-04-22 9:08 ` Ruihan Li
2025-04-22 20:20 ` Andrew Morton
2025-04-22 20:25 ` David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aAZ1RzQdgllQYM04@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lrh2000@pku.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.