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: <cde76a2d8ed54885a77771894ecd3e99@AcuMS.aculab.com>
Date:   Thu, 16 Nov 2023 11:38:08 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'David Howells' <dhowells@...hat.com>
CC:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Borislav Petkov <bp@...en8.de>,
        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>
Subject: RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput
 -16.9% regression

From: David Howells
> Sent: 16 November 2023 10:14
> 
> David Laight <David.Laight@...LAB.COM> wrote:
> 
> > On haswell (which is now quite old) both 'rep movsb' and
> > 'rep movsq' copy 16 bytes/clock unless the destination
> > is 32 byte aligned when they copy 32 bytes/clock.
> > Source alignment make no different, neither does byte
> > alignment.
> 
> I think the i3-4170 cpu I'm using is Haswell.  Does that mean for my
> particular cpu, just using inline "rep movsb" is the best choice?

I've just looked at a slight old copy of the instruction timing
doc from https://www.agner.org/optimize

Apart from P4 (130 clock setup!) the setup cost for 'rep movs'
is relatively small.
I think everything since sandy bridge and bulldozer (except atoms,
but including silvermont) do fast copies for 'rep movsb'.
(But the C2758 atom we use claims erms.)

I'd bet that the overhead for using 'rep movsb' for a short copy
is less than that of the mispredicted branch (or two) to select
the required code.

That rather implies always using 'rep movsb' is best unless
someone is compiling explicitly for an old cpu.
And apart from P4 an explicit 'rep movsl' will be fastest then
because the setup cost is minimal/zero.

The cutoff for using 'rep movsb' for constant sized copies
is probably also a lot less than you might expect.
Especially assuming cold cache.

This all makes that POS that gcc is inlining even more stupid.

	David

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