Re: [PATCH v8 7/9] x86/string: extend memcpy_flushcache() fixed-size fastpaths

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

On Wed, 29 Jul 2026 16:48:42 -0700
Borislav Petkov <bp@alien8.de> wrote:

...
> at least the code is making a lot more sense now.
> 
> The fact that you had to axe off so much cruft off of it tells me that you
> haven't really measured it right.

Especially since if you do actually measure the clock counts (non-trivial)
you'll find that loops are often completely free.
The out-of-order execution unit will (effectively) execute the loop control
instructions to generate a list of instructions that get executed at a
later time.
So provided the loop control doesn't use more clocks than the loop body
(and there are spare ALU units - usually true) loops really make little
difference.

This also means that unrolling loops often doesn't make things faster.
You do need to minimise the loop control instructions (and gcc doesn't
like the best loop that uses negative offsets from the end), and
intel cpu can't execute single clock loops (amd ones can).

Inlining also increases the code size, the I-cache reads are actually
likely to be significant.
You need to time a single 'cold-cache' call not just loops for long
enough that the result is also skewed by timer ticks (etc).

	David 

> 
> So why do I really want your patch?
> 
> Thx.
>