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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67acdf70c3fd4adf9bc0dddd4b10d4a1@AcuMS.aculab.com>
Date:   Fri, 17 Nov 2023 13:09:36 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Borislav Petkov' <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>
CC:     David Howells <dhowells@...hat.com>,
        kernel test robot <oliver.sang@...el.com>,
        "oe-lkp@...ts.linux.dev" <oe-lkp@...ts.linux.dev>,
        "lkp@...el.com" <lkp@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Christian Brauner <brauner@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
        Christian Brauner <christian@...uner.io>,
        Matthew Wilcox <willy@...radead.org>,
        "ying.huang@...el.com" <ying.huang@...el.com>,
        "feng.tang@...el.com" <feng.tang@...el.com>,
        "fengwei.yin@...el.com" <fengwei.yin@...el.com>,
        linux-toolchains ML <linux-toolchains@...r.kernel.org>
Subject: RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput
 -16.9% regression

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)