From: Muchun Song <muchun.song@linux.dev>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: linux-arch@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
akpm@linux-foundation.org, apopple@nvidia.com, arnd@arndb.de,
balbirs@nvidia.com, bp@alien8.de, dave.hansen@linux.intel.com,
david@kernel.org, kees@kernel.org, mingo@redhat.com,
rppt@kernel.org, tglx@kernel.org
Subject: Re: [PATCH v6 4/8] mm: add a template-based fast path for zone-device page init
Date: Tue, 14 Jul 2026 16:38:06 +0800 [thread overview]
Message-ID: <08d40cad-8f61-4aba-9556-5a84067c6494@linux.dev> (raw)
In-Reply-To: <20260709112520.24857-5-lizhe.67@bytedance.com>
On 2026/7/9 19:25, Li Zhe wrote:
> memmap_init_zone_device() repeats nearly identical head-page
> initialization for each PFN. Prepare one reusable ZONE_DEVICE head-page
> template through the existing slow path, refresh the PFN-dependent
> fields in that template before each copy, and memcpy it into each
> destination page.
>
> The optimized path assigns _refcount through the copied template, so
> keep it disabled when the page_ref_set tracepoint is enabled.
>
> This patch accelerates head-page initialization. The pfns_per_compound
> == 1 case gets the full benefit here, compound tails are handled in the
> next patch.
>
> Tested in a VM with a 100 GB fsdax namespace device configured with
> map=dev on Intel Ice Lake server. This test exercises the nd_pmem rebind
> path (pfns_per_compound == 1).
>
> Test procedure:
> Rebind the nd_pmem driver 30 times and collect the memmap initialization
> time from the pr_debug() output of memmap_init_zone_device().
>
> Base(v7.2-rc1):
> First binding: 1456 ms
> Average of subsequent rebinds: 244.28 ms
>
> With this patch and its prerequisites applied:
> First binding: 1440 ms
> Average of subsequent rebinds: 217.19 ms
>
> This reduces the average rebind time from 244.28 ms to 217.19 ms, or
> about 11%.
>
> Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
> ---
> mm/mm_init.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index 5fccfbacf855..170021e182e0 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -1065,6 +1065,44 @@ static void __ref zone_device_page_init_slow(struct page *page,
> set_page_count(page, 0);
> }
>
> +static inline bool zone_device_page_init_optimization_enabled(void)
> +{
> + /*
> + * The template fast path copies a preinitialized struct page image.
> + * Skip it when the page_ref_set tracepoint is enabled.
> + */
> + return !page_ref_tracepoint_active(page_ref_set);
I'm not sure why we need to make this. I think we can go ahead and
perform this optimization unconditionally.
If we look at why the tracepoint was added in the first place, it's
clear that its primary purpose is for debugging, particularly regarding
why CMA memory pages cannot be allocated (see commit 95813b8faa0). But
at this stage, the struct page hasn't even been initialized yet; we
are currently in the middle of initialization. From the perspective of
the page being initialized, the user doesn't need to care at all about
how the reference count is changing. Therefore, I don't think we need to
include these checks. It would only increase the complexity of the code.
I suggest deleting this section of code to keep things simple.
Thanks.
> +}
> +
> +/*
> + * 'template' is a reusable page prototype rather than a strictly immutable
> + * object. Most ZONE_DEVICE fields stay constant across the pages covered by
> + * the current template, but section bits and page->virtual may still depend
> + * on the PFN. Refresh those PFN-dependent fields in the template before
> + * copying it into @page.
> + */
> +static inline void zone_device_page_update_template(struct page *template,
> + unsigned long pfn)
> +{
> + 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
> +}
> +
> +static void zone_device_page_init_from_template(struct page *page,
> + unsigned long pfn, struct page *template)
> +{
> + /*
> + * 'template' carries the invariant portion of a ZONE_DEVICE struct
> + * page. Update the PFN-dependent fields in place before copying it
> + * to the destination page.
> + */
> + zone_device_page_update_template(template, pfn);
> + memcpy(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
> @@ -1120,6 +1158,7 @@ void __ref memmap_init_zone_device(struct zone *zone,
> unsigned long nr_pages,
> struct dev_pagemap *pgmap)
> {
> + bool use_template = zone_device_page_init_optimization_enabled();
> unsigned long pfn, end_pfn = start_pfn + nr_pages;
> struct pglist_data *pgdat = zone->zone_pgdat;
> struct vmem_altmap *altmap = pgmap_altmap(pgmap);
> @@ -1127,6 +1166,7 @@ void __ref memmap_init_zone_device(struct zone *zone,
> unsigned long zone_idx = zone_idx(zone);
> unsigned long start = jiffies;
> int nid = pgdat->node_id;
> + struct page template;
>
> if (WARN_ON_ONCE(!pgmap || zone_idx != ZONE_DEVICE))
> return;
> @@ -1144,7 +1184,24 @@ void __ref memmap_init_zone_device(struct zone *zone,
> for (pfn = start_pfn; pfn < end_pfn; pfn += pfns_per_compound) {
> struct page *page = pfn_to_page(pfn);
>
> - zone_device_page_init_slow(page, pfn, zone_idx, nid, pgmap);
> + if (!use_template) {
> + zone_device_page_init_slow(page, pfn, zone_idx,
> + nid, pgmap);
> + } else if (pfn == start_pfn) {
> + /*
> + * Seed the reusable head-page template from the
> + * first real struct page, because the existing
> + * page-init and pageblock helpers expect a real
> + * memmap entry rather than a stack object.
> + */
> + zone_device_page_init_slow(page, pfn, zone_idx,
> + nid, pgmap);
> + /* init template page */
> + memcpy(&template, page, sizeof(*page));
> + } else {
> + zone_device_page_init_from_template(page, pfn,
> + &template);
> + }
>
> if (IS_ALIGNED(pfn, PAGES_PER_SECTION))
> cond_resched();
> --
> 2.20.1
>
next prev parent reply other threads:[~2026-07-14 8:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 11:25 [PATCH v6 0/8] mm: optimize zone-device memmap initialization Li Zhe
2026-07-09 11:25 ` [PATCH v6 1/8] mm: fix stale ZONE_DEVICE refcount comment Li Zhe
2026-07-14 2:25 ` Muchun Song
2026-07-09 11:25 ` [PATCH v6 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page Li Zhe
2026-07-14 2:44 ` Muchun Song
2026-07-14 11:35 ` Balbir Singh
2026-07-09 11:25 ` [PATCH v6 3/8] mm: add a set_page_section_from_pfn() helper Li Zhe
2026-07-14 2:45 ` Muchun Song
2026-07-14 12:09 ` Balbir Singh
2026-07-09 11:25 ` [PATCH v6 4/8] mm: add a template-based fast path for zone-device page init Li Zhe
2026-07-13 13:28 ` Muchun Song
2026-07-14 8:38 ` Muchun Song [this message]
2026-07-09 11:25 ` [PATCH v6 5/8] mm: extend the template fast path to zone-device compound tails Li Zhe
2026-07-09 11:25 ` [PATCH v6 6/8] string: introduce memcpy_nt() helpers Li Zhe
2026-07-14 9:24 ` Muchun Song
2026-07-09 11:25 ` [PATCH v6 7/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths Li Zhe
2026-07-09 11:25 ` [PATCH v6 8/8] mm: use memcpy_nt() in zone-device template copies Li Zhe
2026-07-14 9:45 ` Muchun Song
2026-07-14 11:22 ` Muchun Song
2026-07-13 1:44 ` [PATCH v6 0/8] mm: optimize zone-device memmap initialization Balbir Singh
2026-07-13 3:18 ` ByteDance
2026-07-13 13:15 ` Muchun Song
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=08d40cad-8f61-4aba-9556-5a84067c6494@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=balbirs@nvidia.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=kees@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@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 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.