On 9/1/26 7:45 AM, Andrew Morton wrote: > On Mon, 31 Aug 2026 19:16:31 +0800 "Li Zhe" <[email protected]> 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/[email protected] > 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. 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? 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
