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
