Re: [PATCH RFC v2] mm: introduce copy_mc_highpages() and batch copy in folio_mc_copy()

[Garg, Shivank]

On Mon, 2026-10-19 at 13:19 +0100, David Laight wrote:
> On Mon, 19 Oct 2026 10:06:49 +0000
> Shivank Garg <shivankg@xxxxxxx> wrote:
> 
> > folio_mc_copy() copies a folio one page at a time with copy_mc_highpage(),
> > so a 2MB folio makes 512 separate copy_mc_to_kernel() calls. Each page
> > pays the startup cost of the string instruction ("REP; MOVSB" on x86
> > CPUs with ERMS) plus a cond_resched().
> 
> Don't you always want to use 'rep movsq' for these aligned copies (on any
> cpu anyone cares about).
> I'm pretty even on some that don't advertise ERMS. 
> 
> The fastest a copy loop is ever going to run (on anything but the latest cpu)
> is one write every clock - so 8 bytes/clock.
> A 4k page will then take at least 512 clocks.
> Even an old sandy bridge cpu will (IIRC) copy 32 bytes/clock if the destination
> is 32 byte aligned (not much later cpu double that for 64byte aligned destinations).
> So the copy part takes at most 128 clocks.
> That makes 'rep movsq' faster unless the fixed overhead is in the P4 netburst
> range.
> (I was using lfence when I did my performance measurements, it hides
> the fixed latency of rep.)
> 
> I've never measured zen 1-4.
> 
> I also suspect the slow part of a 2M copy is all the D-cache misses
> (especially on the read side).
> 
> OTOH the longer copy is likely to be better...
> 

Thanks for taking a look and for the detailed explanation.

In my measurements, 'rep movsb' and 'rep movsq' perform about the
same for aligned, longer copies.

Since copy_mc_to_kernel() takes an arbitrary length, always using
'rep movsq' would mean adding an alignment/length, etc. or adding a
separate copy_mc_pages() (or something similar) for page-aligned copies.

I think that would be worthwhile x86 change on its own, independent of
this series. Here, I'm not changing the underlying copy mechanism and
behavior other callers.
 
Would it be okay to have hardware specific changes separately?


Thanks,
Shivank