From: David Hildenbrand <david@redhat.com>
To: David Woodhouse <dwmw2@infradead.org>, Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Sauerwein, David" <dssauerw@amazon.de>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Ard Biesheuvel <ardb@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Ruihan Li <lrh2000@pku.edu.cn>
Subject: Re: [PATCH v4 7/7] mm/mm_init: Use for_each_valid_pfn() in init_unavailable_range()
Date: Fri, 25 Apr 2025 22:12:49 +0200 [thread overview]
Message-ID: <8fd728cf-bc54-433d-8701-234a67933a97@redhat.com> (raw)
In-Reply-To: <91CA8854-2E86-4AF3-BAD0-8C47833F59D4@infradead.org>
On 25.04.25 21:08, David Woodhouse wrote:
> On 25 April 2025 17:17:25 BST, David Hildenbrand <david@redhat.com> wrote:
>> On 23.04.25 15:33, David Woodhouse wrote:
>>> From: David Woodhouse <dwmw@amazon.co.uk>
>>>
>>> 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.
>>>
>>> Use for_each_valid_pfn() to skip the pointless iterations.
>>>
>>> Reported-by: Ruihan Li <lrh2000@pku.edu.cn>
>>> Suggested-by: Mike Rapoport <rppt@kernel.org>
>>> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>>> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>>> Tested-by: Ruihan Li <lrh2000@pku.edu.cn>
>>> ---
>>> mm/mm_init.c | 6 +-----
>>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>>
>>> diff --git a/mm/mm_init.c b/mm/mm_init.c
>>> index 41884f2155c4..0d1a4546825c 100644
>>> --- a/mm/mm_init.c
>>> +++ b/mm/mm_init.c
>>> @@ -845,11 +845,7 @@ static void __init init_unavailable_range(unsigned long spfn,
>>> unsigned long pfn;
>>> u64 pgcnt = 0;
>>> - for (pfn = spfn; pfn < epfn; pfn++) {
>>> - if (!pfn_valid(pageblock_start_pfn(pfn))) {
>>> - pfn = pageblock_end_pfn(pfn) - 1;
>>> - continue;
>>> - }
>>
>> So, if the first pfn in a pageblock is not valid, we skip the whole pageblock ...
>>
>>> + for_each_valid_pfn(pfn, spfn, epfn) {
>>> __init_single_page(pfn_to_page(pfn), pfn, zone, node);
>>> __SetPageReserved(pfn_to_page(pfn));
>>> pgcnt++;
>>
>> but here, we would process further pfns inside such a pageblock?
>>
>
> Is it not the case that either *all*, or *none*, of the PFNs within a given pageblock will be valid?
Hmm, good point. I was thinking about sub-sections, but all early
sections are fully valid.
(Also, at least on x86, the subsection size should match the pageblock
size; might not be the case on other architectures, like arm64 with 64K
base pages ...)
>
> I assumed that was *why* it had that skip, as an attempt at the kind of optimisation that for_each_valid_pfn() now gives us?
But it's interesting in this code that we didn't optimize for "if the
first pfn is valid, all the remaining ones are valid". We would still
check each PFN.
In any case, trying to figure out why Lorenzo ran into an issue ... if
it's nit because of the pageblock, maybe something in for_each_valid_pfn
with sparsemem is still shaky.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2025-04-25 20:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-23 13:33 [PATCH v4 0/7] mm: Introduce for_each_valid_pfn() David Woodhouse
2025-04-23 13:33 ` [PATCH v4 1/7] mm: Introduce for_each_valid_pfn() and use it from reserve_bootmem_region() David Woodhouse
2025-04-24 21:11 ` David Hildenbrand
2025-04-25 22:01 ` David Woodhouse
2025-04-28 7:06 ` David Hildenbrand
2025-04-23 13:33 ` [PATCH v4 2/7] mm: Implement for_each_valid_pfn() for CONFIG_FLATMEM David Woodhouse
2025-04-24 21:13 ` David Hildenbrand
2025-04-23 13:33 ` [PATCH v4 3/7] mm: Implement for_each_valid_pfn() for CONFIG_SPARSEMEM David Woodhouse
2025-04-23 13:33 ` [PATCH v4 4/7] mm, PM: Use for_each_valid_pfn() in kernel/power/snapshot.c David Woodhouse
2025-04-23 13:33 ` [PATCH v4 5/7] mm, x86: Use for_each_valid_pfn() from __ioremap_check_ram() David Woodhouse
2025-04-23 13:33 ` [PATCH v4 6/7] mm: Use for_each_valid_pfn() in memory_hotplug David Woodhouse
2025-04-24 21:15 ` David Hildenbrand
2025-04-23 13:33 ` [PATCH v4 7/7] mm/mm_init: Use for_each_valid_pfn() in init_unavailable_range() David Woodhouse
2025-04-25 16:11 ` Lorenzo Stoakes
2025-04-25 23:38 ` Andrew Morton
2025-04-26 8:30 ` David Woodhouse
2025-04-27 23:07 ` Andrew Morton
2025-04-28 8:25 ` Lorenzo Stoakes
2025-04-25 16:17 ` David Hildenbrand
2025-04-25 19:08 ` David Woodhouse
2025-04-25 20:12 ` David Hildenbrand [this message]
2025-04-25 20:36 ` David Woodhouse
2025-04-25 23:04 ` David Woodhouse
2025-04-28 7:12 ` David Hildenbrand
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=8fd728cf-bc54-433d-8701-234a67933a97@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dssauerw@amazon.de \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lrh2000@pku.edu.cn \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox