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

["Li Zhe" <lizhe.67@bytedance.com>]

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.

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