Re: [PATCH v11 0/7] mm: optimize zone-device memmap initialization

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 1 Sep 2026 10:58:09 +0800 "Li Zhe" <lizhe.67@bytedance.com> wrote:

> On 9/1/26 7:45 AM, Andrew Morton wrote:
> > On Mon, 31 Aug 2026 19:16:31 +0800 "Li Zhe" <lizhe.67@bytedance.com> wrote:
> >
> >> memmap_init_zone_device() can take a noticeable amount of time when large
> >> pmem namespaces are bound or rebound, because it initializes nearly
> >> identical struct page descriptors one PFN at a time. This series reduces
> >> that ZONE_DEVICE memmap initialization overhead by reusing prepared
> >> struct page templates and, on x86, using memcpy_nontemporal() for the
> >> template copy path.
> >>
> >> ...
> >>
> >> This reduces the average memmap initialization time measured during
> >> rebind by about 48.0% for nd_pmem and 41.6% for dax_pmem on that arm64
> >> VM setup. Since this arm64 setup does not use the x86 MOVNTI fast paths,
> >> the result also suggests that the generic template-copy optimization can
> >> benefit architectures without an architecture-specific
> >> memcpy_nontemporal() backend.
> > Well that's nice.
> >
> > Sashiko seems to have found some new things to complain about:
> > 	https://sashiko.dev/#/patchset/20260831111638.76012-1-lizhe.67@bytedance.com
> >
> Hi Andrew,
> 
> Thanks for taking a look.
> 
> For the comment on patch 5 about the cnt == 0 case, I agree that
> memcpy_flushcache() should preserve the usual zero-length memcpy
> semantics. This is a pre-existing issue in the x86
> memcpy_flushcache()/__memcpy_flushcache() implementation, not a bug
> introduced by this series. The new ZONE_DEVICE call site added by this
> series always copies sizeof(struct page), so it cannot hit the
> zero-length case.

OK, thanks.

> Since this is a pre-existing issue and is independent of this patchset,
> would you prefer me to send a separate standalone fix for the x86
> memcpy_flushcache() zero-length case, rather than folding it into this
> series?

A standalone thing please.  It sounds like a candidate for the x86
tree, as long as Sashiko is wrong in implying that your [5/7] could
trigger this bug.

> For the MOVNTI ordering concern in patch 6, this was discussed in the
> previous round. Based on that discussion, I believe the current code is
> correct, so I do not plan any additional code changes for these items.
> 
> Thanks,
> Zhe