On Tue, 1 Sep 2026 10:58:09 +0800 "Li Zhe" <[email protected]> wrote:
> 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. 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
