Re: [PATCH v2] x86/lib: Use REP MOVSB for large memcpy() on ERMS CPUs without FSRM

[David Laight <david.laight.linux@gmail.com>]

On Tue, 10 Nov 2026 09:53:07 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, 4 Nov 2026 at 14:28, Usama Arif <usama.arif@linux.dev> wrote:
> >
> > +       ALTERNATIVE __stringify(cmpq $0x20, %rcx; jb .Lhandle_tail), \
> > +                   __stringify(rep movsb; RET), X86_FEATURE_FSRM  
> 
> Let's not do that.
> 
> Putting magic things like RET in alternatives is just a bad bad idea.

You'd definitely want the RET in the code itself, and then overwrite
it with something else.
When I suggested it I did wonder whether the code patching really had
the right functionality.

Someone should try to measure it [1], but I actually suspect that the only
cost in following a 'rep movs' with an unconditional 'jmp' would be
for an I-cache load (or, worse, a TLB miss).
I expect the pipeline front end (which handles the jmp) will do all its
work while the setup for rep movs is happening (even for FSRM).

That would mean you could pair the "cmpq $0x20, %rcx; jb .Lhandle_tail"
with "rep movsb; jmps do_RET; nop".

David

[1] I need to dig out my 'rep movs' performance measuring code and run
it on a few different cpu types.
But I not got anything newer than an i7-7 or a zen[1-4].

> 
>                Linus