mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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
>

  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®