Re: [PATCH RFC v2 1/3] mm, x86: support copying a folio using non-temporal stores

On Fri, 2026-07-31 at 14:53 -0700, Huan Nguyen wrote:
> Hi Yiannis,
> 
> Although copy_mc_to_kernel_nt() asserts both "mc" (machine check exception)
> and "nt" (non-temporal store), the implementation fails to deliver both:
> 1. copy_mc_fragile() is MCE-safe, but it does not use movnti.
> 2. memcpy_flushcache() uses movnti, but it is not MCE-safe.
> 
> Additionally, according to the Intel manual, since movnti uses the WC protocol
> (a weakly-ordered memory model), a fencing operation is required. Because
> memcpy_flushcache() lacks an sfence, it can result in reading stale or corrupted
> data after folio_unlock().
> 
> Furthermore, copy_mc_highpage() is unoptimized for page migration operations
> because it reuses copy_mc_to_kernel(), built to handle
> variable-length, unaligned
> memory. As copy_mc_highpage_nt() follows copy_mc_highpage(), it inherits this
> flaw. In contrast, copy_highpage() is optimized for page migration by leveraging
> copy_page(), dedicated to 4KiB-aligned memory.
> 

I don't think copy_mc_highpage() is unoptimized for page migration copies.

On ERMS systems, copy_mc_to_kernel() uses copy_mc_enhanced_fast_string(),
which is rep movsb. copy_page() uses rep movsq on REP_GOOD systems.

(The copy_mc_fragile_enabled path looks like a special case and
enable_copy_mc_fragile() is reachable either when mce=recovery or through
one of 4 intel CPUs in x86/kernel/quirks.c)

In my testing on AMD EPYC 9655 (ZEN 5), both folio_mc_copy() and
folio_copy() showed similar performance.

https://lore.kernel.org/all/[email protected]

And there is actually scope of upto ~2X speedup for
folio_copy/folio_mc_copy for large pages if we batch 4KiB copies. 

Thanks,
Shivank