Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
From:   David Laight <David.Laight@ACULAB.COM>
To:     'David Howells' <dhowells@redhat.com>
CC:     'Linus Torvalds' <torvalds@linux-foundation.org>,
        Borislav Petkov <bp@alien8.de>,
        kernel test robot <oliver.sang@intel.com>,
        "oe-lkp@lists.linux.dev" <oe-lkp@lists.linux.dev>,
        "lkp@intel.com" <lkp@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Christian Brauner <brauner@kernel.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
        Christian Brauner <christian@brauner.io>,
        Matthew Wilcox <willy@infradead.org>,
        "ying.huang@intel.com" <ying.huang@intel.com>,
        "feng.tang@intel.com" <feng.tang@intel.com>,
        "fengwei.yin@intel.com" <fengwei.yin@intel.com>
Subject: RE: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput
 -16.9% regression
Thread-Topic: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput
 -16.9% regression
Thread-Index: AQHaF/9mUr/d/cPMC0WC86r1pNT+UrB8tOywgAAGVICAAAkJMA==
Date:   Thu, 16 Nov 2023 11:38:08 +0000
Message-ID: <cde76a2d8ed54885a77771894ecd3e99@AcuMS.aculab.com>
References: <4c0c3ee6cfa84d21a807055bc1aa27b8@AcuMS.aculab.com>
 <202311061616.cd495695-oliver.sang@intel.com>
 <3865842.1700061614@warthog.procyon.org.uk>
 <CAHk-=whM-cEwAsLtKsf5dYwV7nDTaRv1bUKLVBstMAQBug24uQ@mail.gmail.com>
 <CAHk-=wjCUckvZUQf7gqp2ziJUWxVpikM_6srFdbcNdBJTxExRg@mail.gmail.com>
 <CAHk-=wjhs6uuedgz-7HbcPtirEq+vvjJBY-M2zyteJwBhOMZhg@mail.gmail.com>
 <20231115190938.GGZVUXcuUjI3i1JRAB@fat_crate.local>
 <CAHk-=whFW+uWOmOtRNh0What_fu8Xo8KF2+EeUH1kn4qFxGAhA@mail.gmail.com>
 <CAHk-=whrc-ruKs4Kt90EGzKd+pYhZFKs6bgBVCV=55BK+p1nzg@mail.gmail.com>
 <97468.1700129643@warthog.procyon.org.uk>
In-Reply-To: <97468.1700129643@warthog.procyon.org.uk>
Accept-Language: en-GB, en-US
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

From: David Howells
> Sent: 16 November 2023 10:14
> 
> David Laight <David.Laight@ACULAB.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)