All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: akpm@linux-foundation.org, arnd@arndb.de, bp@alien8.de,
	 dave.hansen@linux.intel.com, david@kernel.org, kees@kernel.org,
	mingo@redhat.com,  rppt@kernel.org, tglx@kernel.org,
	linux-arch@vger.kernel.org,  linux-hardening@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH v5 4/8] mm: add a template-based fast path for zone-device page init
Date: Tue, 7 Jul 2026 13:02:52 +1000	[thread overview]
Message-ID: <akxpS3WOP7oUBNKF@nvdebian.thelocal> (raw)
In-Reply-To: <20260701090553.62691-5-lizhe.67@bytedance.com>

On 2026-07-01 at 19:05 +1000, Li Zhe <lizhe.67@bytedance.com> 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 | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 74 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index 4c7fad440c2a..cc8417951467 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -1066,6 +1066,50 @@ 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);
> +}
> +
> +static inline void zone_device_template_page_init(struct page *template,
> +						  struct page *src)
> +{
> +	memcpy(template, src, sizeof(*template));

I'd drop this function and just open-code the memcpy as I think that ends up
being clearer and removes a naming confusion - I kept mixing up the purpose of
`zone_device_template_page_init` and `zone_device_page_init_from_template`

> +}
> +
> +/*
> + * '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
> @@ -1121,6 +1165,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);
> @@ -1128,6 +1173,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;
> @@ -1142,10 +1188,36 @@ void __ref memmap_init_zone_device(struct zone *zone,
>  		nr_pages = end_pfn - start_pfn;
>  	}
>  
> -	for (pfn = start_pfn; pfn < end_pfn; pfn += pfns_per_compound) {
> -		struct page *page = pfn_to_page(pfn);
> +
> +	if (!nr_pages)
> +		return;
> +
> +	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.
> +	 */
> +	if (use_template) {
> +		struct page *page = pfn_to_page(start_pfn);
>  
>  		zone_device_page_init_slow(page, pfn, zone_idx, nid, pgmap);
> +		zone_device_template_page_init(&template, page);
> +		if (pfns_per_compound != 1)
> +			memmap_init_compound(page, pfn, zone_idx, nid, pgmap,
> +				compound_nr_pages(start_pfn, altmap, pgmap));
> +		pfn += pfns_per_compound;

I think it would be clearer and less error prone to not unroll the loop here.
Instead just initialise the template page and leave the for loop starting at
pfn = start_pfn and let it handle the rest of the steps. I can't imagine the
extra call to zone_deivce_page_init_from_template() would cause a noticable
perf impact.

It also avoids the obvious danger of someone updating the loop but missing the
unrolled version above.

 - Alistair

> +	}
> +
> +	for (; pfn < end_pfn; pfn += pfns_per_compound) {
> +		struct page *page = pfn_to_page(pfn);
> +
> +		if (use_template)
> +			zone_device_page_init_from_template(page, pfn,
> +							    &template);
> +		else
> +			zone_device_page_init_slow(page, pfn, zone_idx,
> +						   nid, pgmap);
>  
>  		if (IS_ALIGNED(pfn, PAGES_PER_SECTION))
>  			cond_resched();
> -- 
> 2.20.1

  parent reply	other threads:[~2026-07-07  3:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-01  9:05 [PATCH v5 0/8] mm: optimize zone-device memmap initialization Li Zhe
2026-07-01  9:05 ` [PATCH v5 1/8] mm: fix stale ZONE_DEVICE refcount comment Li Zhe
2026-07-06  9:11   ` David Hildenbrand (Arm)
2026-07-07  2:28   ` Alistair Popple
2026-07-01  9:05 ` [PATCH v5 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page Li Zhe
2026-07-06  9:13   ` David Hildenbrand (Arm)
2026-07-06 11:50     ` Li Zhe
2026-07-06 13:47       ` David Hildenbrand (Arm)
2026-07-07  3:25         ` Li Zhe
2026-07-01  9:05 ` [PATCH v5 3/8] mm: add a set_page_section_from_pfn() helper Li Zhe
2026-07-06  9:15   ` David Hildenbrand (Arm)
2026-07-06 11:52     ` Li Zhe
2026-07-06 13:48       ` David Hildenbrand (Arm)
2026-07-07  3:26         ` Li Zhe
2026-07-01  9:05 ` [PATCH v5 4/8] mm: add a template-based fast path for zone-device page init Li Zhe
2026-07-03 14:06   ` Mike Rapoport
2026-07-06  7:45     ` Li Zhe
2026-07-07  3:06       ` Alistair Popple
2026-07-07  6:36         ` Li Zhe
2026-07-07  3:02   ` Alistair Popple [this message]
2026-07-07  6:33     ` Li Zhe
2026-07-01  9:05 ` [PATCH v5 5/8] mm: extend the template fast path to zone-device compound tails Li Zhe
2026-07-07  3:09   ` Alistair Popple
2026-07-07  6:38     ` Li Zhe
2026-07-01  9:05 ` [PATCH v5 6/8] string: introduce memcpy_nt() helpers Li Zhe
2026-07-02  2:16   ` Borislav Petkov
2026-07-02  7:36     ` Li Zhe
2026-07-06  9:18   ` David Hildenbrand (Arm)
2026-07-06 11:53     ` Li Zhe
2026-07-06 13:49       ` David Hildenbrand (Arm)
2026-07-07  3:28         ` Li Zhe
2026-07-01  9:05 ` [PATCH v5 7/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths Li Zhe
2026-07-02  2:23   ` Borislav Petkov
2026-07-02  7:37     ` Li Zhe
2026-07-03 19:56       ` Borislav Petkov
2026-07-06  7:43         ` Li Zhe
2026-07-06 17:19           ` Borislav Petkov
2026-07-07 11:34             ` Li Zhe
2026-07-01  9:05 ` [PATCH v5 8/8] mm: use memcpy_nt() in zone-device template copies Li Zhe
2026-07-01 23:28 ` [PATCH v5 0/8] mm: optimize zone-device memmap initialization Andrew Morton
2026-07-02  2:24   ` Borislav Petkov
2026-07-02  7:39   ` 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=akxpS3WOP7oUBNKF@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --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.