From: "Li Zhe" <lizhe.67@bytedance.com>
To: "Muchun Song" <muchun.song@linux.dev>,
"Balbir Singh" <balbirs@nvidia.com>
Cc: <osalvador@suse.de>, <david@kernel.org>,
<akpm@linux-foundation.org>, <rppt@kernel.org>,
<apopple@nvidia.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mm/mm_init: factor out memmap_init_page_from_template()
Date: Mon, 9 Nov 2026 11:05:36 +0800 [thread overview]
Message-ID: <2f9730df-fade-4c5f-a4fe-fd3d43eb8bba@bytedance.com> (raw)
In-Reply-To: <f062d92e-a016-447f-926f-bd1b1ce7f106@linux.dev>
On 11/9/26 10:57 AM, Muchun Song wrote:
>
>
> On 2026/11/9 10:51, Li Zhe wrote:
>> On 11/6/26 6:34 PM, Balbir Singh wrote:
>>> On Thu, Nov 05, 2026 at 08:06:14PM +0800, Li Zhe wrote:
>>>> ZONE_DEVICE memmap initialization already uses a reusable struct page
>>>> template when initializing compound tail pages. The template mostly
>>>> contains invariant state, but a few fields still depend on the target
>>>> PFN and must be refreshed before copying the template into each
>>>> destination struct page.
>>>>
>>>> Factor that operation into memmap_init_page_from_template() so other
>>>> boot-time memmap initialization paths can reuse the same helper.
>>>>
>>>> No functional change intended.
>>>>
>>>> Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
>>>> ---
>>>> mm/mm_init.c | 29 +++++++++++++++--------------
>>>> mm/mm_init.h | 2 ++
>>>> 2 files changed, 17 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/mm/mm_init.c b/mm/mm_init.c
>>>> index 2a0e782a151d..495e20fbdec0 100644
>>>> --- a/mm/mm_init.c
>>>> +++ b/mm/mm_init.c
>>>> @@ -625,6 +625,17 @@ void __meminit __init_single_page(struct page
>>>> *page, unsigned long pfn,
>>>> vmemmap_optimization_verify_zone(page);
>>>> }
>>>> +void __meminit memmap_init_page_from_template(struct page *page,
>>>> + unsigned long pfn, unsigned long zone, struct page *template)
>>>> +{
>>>> + set_page_section_from_pfn(template, pfn);
>>>> +#ifdef WANT_PAGE_VIRTUAL
>>>> + if (!is_highmem_idx(zone))
>>>> + set_page_address(template, __va(pfn << PAGE_SHIFT));
>>>> +#endif
>>>> + memcpy_nontemporal(page, template, sizeof(*page));
>>>> +}
>>>> +
>>> Can we make the template a const? Why can't we do
>>>
>>> void __meminit memmap_init_page_from_template(struct page *page,
>>> unsigned long pfn, unsigned long zone,
>>> const struct page *template)
>>> {
>>> memcpy_nontemporal(page, template, sizeof(*page));
>>>
>>> set_page_section_from_pfn(page, pfn);
>>> #ifdef WANT_PAGE_VIRTUAL
>>> if (!is_highmem_idx(zone))
>>> set_page_address(page, __va(pfn << PAGE_SHIFT));
>>> #endif
>>>
>>> That way we don't update template once it is set, if template is r/o,
>>> then we don't need both first page and template in the caller to
>>> be different.
>
> I used to think that too.
>
>> I kept it this way to preserve the memcpy_nontemporal() write pattern:
>> update the PFN-dependent fields in the template first, then copy the
>> final state to the destination page once.
>>
>> If we copy first and then update the destination page, the hot loop
>> would do a non-temporal copy followed by normal stores to the same
>> struct page. That is the pattern this helper avoids.
>
> After thinking it through, that should be the reason. To prevent
> similar confusion for others, I suggest adding a comment here
> explaining why this specific order is used.
Agreed, thanks. I will add a short comment in v2.
Thanks,
Zhe
>
> Thanks.
>
>>
>> Thanks,
>> Zhe
>>>> #ifdef CONFIG_NUMA
>>>> /*
>>>> * During memory init memblocks map pfns to nids. The search is
>>>> expensive and
>>>> @@ -1073,17 +1084,6 @@ static void __ref
>>>> __init_zone_device_page(struct page *page, unsigned long pfn,
>>>> }
>>>> }
>>>> -static void zone_device_page_init_from_template(struct page *page,
>>>> - unsigned long pfn, struct page *template)
>>>> -{
>>>> - set_page_section_from_pfn(template, pfn);
>>>> -#ifdef WANT_PAGE_VIRTUAL
>>>> - if (!is_highmem_idx(ZONE_DEVICE))
>>>> - set_page_address(template, __va(pfn << PAGE_SHIFT));
>>>> -#endif
>>>> - memcpy_nontemporal(page, template, sizeof(*page));
>>>> -}
>>>> -
>>>> /*
>>>> * With compound page geometry and when struct pages are stored
>>>> in ram most
>>>> * tail pages are reused. Consequently, the amount of unique
>>>> struct pages to
>>>> @@ -1136,8 +1136,8 @@ static void __ref memmap_init_compound(struct
>>>> page *head,
>>>> /* Initialize the remaining tail pages from template. */
>>>> for (pfn = head_pfn + 2; pfn < end_pfn; pfn++)
>>>> - zone_device_page_init_from_template(pfn_to_page(pfn), pfn,
>>>> - &template);
>>>> + memmap_init_page_from_template(pfn_to_page(pfn), pfn,
>>>> + ZONE_DEVICE, &template);
>>>> prep_compound_head(head, order);
>>>> }
>>>> @@ -1192,7 +1192,8 @@ void __ref memmap_init_zone_device(struct
>>>> zone *zone,
>>>> for (; pfn < end_pfn; pfn += pfns_per_compound) {
>>>> page = pfn_to_page(pfn);
>>>> - zone_device_page_init_from_template(page, pfn, &template);
>>>> + memmap_init_page_from_template(page, pfn, ZONE_DEVICE,
>>>> + &template);
>>>> if (IS_ALIGNED(pfn, PAGES_PER_SECTION))
>>>> cond_resched();
>>>> diff --git a/mm/mm_init.h b/mm/mm_init.h
>>>> index 0034e37dbabd..22c465122b47 100644
>>>> --- a/mm/mm_init.h
>>>> +++ b/mm/mm_init.h
>>>> @@ -111,5 +111,7 @@ void memblock_free_all(void);
>>>> void __meminit __init_single_page(struct page *page, unsigned
>>>> long pfn,
>>>> unsigned long zone, int nid);
>>>> +void __meminit memmap_init_page_from_template(struct page *page,
>>>> + unsigned long pfn, unsigned long zone, struct page
>>>> *template);
>>>> #endif /* __MM_MM_INIT_H */
>>>> --
>>> Balbir
>
next prev parent reply other threads:[~2026-11-09 3:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 12:06 [PATCH 0/2] mm: optimize HugeTLB bootmem hugepage init Li Zhe
2026-11-05 12:06 ` [PATCH 1/2] mm/mm_init: factor out memmap_init_page_from_template() Li Zhe
2026-11-06 10:34 ` Balbir Singh
2026-11-09 2:51 ` Li Zhe
2026-11-09 2:57 ` Muchun Song
2026-11-09 3:05 ` Li Zhe [this message]
2026-11-05 12:06 ` [PATCH 2/2] mm/hugetlb: optimize bootmem hugepage tail vmemmap init Li Zhe
2026-11-06 10:23 ` Balbir Singh
2026-11-09 3:01 ` Li Zhe
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=2f9730df-fade-4c5f-a4fe-fd3d43eb8bba@bytedance.com \
--to=lizhe.67@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=rppt@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
all inboxes | Powered by JetHome®