> On Aug 3, 2026, at 15:09, Li Zhe <[email protected]> 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.
>
> Use the template path unconditionally, as suggested by Muchun. The
> page_ref_set tracepoint is primarily a debugging aid, while this code is
> still initializing struct pages before they are handed out. From the
> perspective of users of those pages, the initialization-time refcount
> transitions are not part of the observable page lifetime.
>
> This means page_ref_set will no longer observe every initialization-time
> refcount assignment for copied ZONE_DEVICE head pages. The impact is
> controlled because the final initialized struct page state is unchanged,
> and keeping a separate non-template path only for this local tracepoint
> observability would add complexity to the common path.
>
> 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):
> Average of rebinds for nd_pmem driver: 244.28 ms
>
> With this patch and its prerequisites applied:
> Average of rebinds for nd_pmem driver: 215.55 ms
>
> This reduces the average memmap initialization time measured during rebind
> from 244.28 ms to 215.55 ms, or about 11%.
>
> Suggested-by: Muchun Song <[email protected]>
I personally feel you might have used the wrong trailer here, because it
implies that the overall design is based on someone's suggestion. But for me,
I think what you actually meant is that in a previous version, I made a
suggestion about simplifying the code, rather than dictating the overall
direction of this entire patch series. So I feel I shouldn't be credited here.
This information is already enough just appearing in the change log.
Muchun,
Thanks.
