Messages in this thread | | | From | David Laight <> | Subject | RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression | Date | Fri, 17 Nov 2023 13:09:36 +0000 |
| |
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)
| |