RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression

David Laight
2023-11-17T13:09:37Z

From: Borislav Petkov
> Sent: 17 November 2023 11:44
...
> Yeah, I think we should measure the libcall thing and then try to get
> the inlined "rep movsb" working and see which one is better. You do have
> a point about that RET overhead after each CALL.

You might be able to use the relocation list for memcpy()
to change the 5 byte call instruction into the inline
'mov %rdx,%rcx; rep movsb' sequence.

I've spent all morning (on holiday) trying to understand the strange
timings I'm seeing for 'rep mosvb' on in i7-7700.

The fixed overhead is very strange.

The first 'rep movsb' I do in a process takes an extra 5000 clocks or so.
But it doesn't seem to matter when I do it!
I can do it on entry to main() with several system calls before
the timing loop.

After that the fixed overhead for the 'rep movsb' is fairly small.
I've a few extra register moves between the 'rep movsb' but
I'd guess at about 30 clocks.
All sizes up to (at least) 32 bytes execute in the same time.
After that it increases at much the rate you'd expect.

Zero length copies are different, they always take ~60 clocks.

My current guess for the 5000 clocks is that the logic to
decode 'rep movsb' is loaded into a buffer that is also used
to decode some other instructions.
So if still contains the 'rep movsb' decoder it is fast, otherwise
it is slow.

No idea what other instructions might be using the same logic
(microcode?) buffer.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)