Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <202311061616.cd495695-oliver.sang@intel.com> <3865842.1700061614@warthog.procyon.org.uk>
 <CAHk-=whM-cEwAsLtKsf5dYwV7nDTaRv1bUKLVBstMAQBug24uQ@mail.gmail.com> <CAHk-=wjCUckvZUQf7gqp2ziJUWxVpikM_6srFdbcNdBJTxExRg@mail.gmail.com>
In-Reply-To: <CAHk-=wjCUckvZUQf7gqp2ziJUWxVpikM_6srFdbcNdBJTxExRg@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 15 Nov 2023 13:38:18 -0500
Message-ID: <CAHk-=wjhs6uuedgz-7HbcPtirEq+vvjJBY-M2zyteJwBhOMZhg@mail.gmail.com>
Subject: Re: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput
 -16.9% regression
To:     David Howells <dhowells@redhat.com>, Borislav Petkov <bp@alien8.de>
Cc:     kernel test robot <oliver.sang@intel.com>, oe-lkp@lists.linux.dev,
        lkp@intel.com, 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>,
        David Laight <David.Laight@aculab.com>, ying.huang@intel.com,
        feng.tang@intel.com, fengwei.yin@intel.com
Content-Type: multipart/mixed; boundary="000000000000059111060a3536ba"
Precedence: bulk

--000000000000059111060a3536ba
Content-Type: text/plain; charset="UTF-8"

On Wed, 15 Nov 2023 at 12:38, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The gcc code generation here is *really* odd. I've never seen this
> before, so it may be new to newer versions of gcc. [...]

Ok, so I've been annoyed by gcc code generation for 'memcpy()' before,
mainly because it can't do the "let's inline it as an ALTERNATIVE() of
'rep movs' or an out-of-line call" thing that we do for user copies.

So here's a complete hack that says "we override the
__builtin_memcpy() implementation for non-constant lengths". We
stillwant gcc to deal with the constant size case, since often that
can be turned into just plain moves.

And this is *ENTIRELY* untested, except for checking that it makes the
code generation in lib/iov_iter.c look better.

It's probably completely broken. I particularly worry about "memcpy()"
being used *during* the instruction rewriting, so the whole approach
with ALTERNATIVE() is probably entirely broken.

But I'm cc'ing Borislav, because we've talked about the whole "inline
memcpy() with alternatives" before, so maybe this gives Borislav some
ideas for how to do it right.

Borislav, see

    https://lore.kernel.org/all/CAHk-=wjCUckvZUQf7gqp2ziJUWxVpikM_6srFdbcNdBJTxExRg@mail.gmail.com/

for some truly crazy code generation by gcc.

                   Linus

--000000000000059111060a3536ba
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_lp03tds80>
X-Attachment-Id: f_lp03tds80

IGFyY2gveDg2L2luY2x1ZGUvYXNtL3N0cmluZ182NC5oIHwgMjIgKysrKysrKysrKysrKysrKysr
KysrKwogaW5jbHVkZS9saW51eC9mb3J0aWZ5LXN0cmluZy5oICAgfCAgMSArCiAyIGZpbGVzIGNo
YW5nZWQsIDIzIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9zdHJpbmdfNjQuaCBiL2FyY2gveDg2L2luY2x1ZGUvYXNtL3N0cmluZ182NC5oCmluZGV4IDg1
N2QzNjRiOTg4OC4uYzYyM2Y0MTY3ODlhIDEwMDY0NAotLS0gYS9hcmNoL3g4Ni9pbmNsdWRlL2Fz
bS9zdHJpbmdfNjQuaAorKysgYi9hcmNoL3g4Ni9pbmNsdWRlL2FzbS9zdHJpbmdfNjQuaApAQCAt
NCw2ICs0LDEwIEBACiAKICNpZmRlZiBfX0tFUk5FTF9fCiAjaW5jbHVkZSA8bGludXgvanVtcF9s
YWJlbC5oPgorI2luY2x1ZGUgPGxpbnV4L2NvbXBpbGVyLmg+CisjaW5jbHVkZSA8bGludXgvY29u
c3QuaD4KKyNpbmNsdWRlIDxhc20vYWx0ZXJuYXRpdmUuaD4KKyNpbmNsdWRlIDxhc20vY3B1ZmVh
dHVyZXMuaD4KIAogLyogV3JpdHRlbiAyMDAyIGJ5IEFuZGkgS2xlZW4gKi8KIApAQCAtMTgsNiAr
MjIsMjQgQEAKIGV4dGVybiB2b2lkICptZW1jcHkodm9pZCAqdG8sIGNvbnN0IHZvaWQgKmZyb20s
IHNpemVfdCBsZW4pOwogZXh0ZXJuIHZvaWQgKl9fbWVtY3B5KHZvaWQgKnRvLCBjb25zdCB2b2lk
ICpmcm9tLCBzaXplX3QgbGVuKTsKIAorZXh0ZXJuIF9fYWx3YXlzX2lubGluZSB2b2lkICpfX3Jl
cF9tb3ZzX21lbWNweSh2b2lkICp0bywgY29uc3Qgdm9pZCAqZnJvbSwgc2l6ZV90IGxlbikKK3sK
Kwlhc20gdm9sYXRpbGUoQUxURVJOQVRJVkUoCisJCSJyZXAgbW92c2IiLAorCQkiY2FsbCByZXBf
bW92c19hbHRlcm5hdGl2ZSIsCisJCUFMVF9OT1QoWDg2X0ZFQVRVUkVfRlNSTSkpCisJOiIrYyIg
KGxlbiksICIrRCIgKHRvKSwgIitTIiAoZnJvbSksIEFTTV9DQUxMX0NPTlNUUkFJTlQKKwk6IDog
Im1lbW9yeSIsICJyYXgiKTsKKwlyZXR1cm4gdG87Cit9CisKKyNkZWZpbmUgX19idWlsdGluX21l
bWNweSh0bywgZnJvbSwgbGVuKSBcCisJX19idWlsdGluX2Nob29zZV9leHByKF9faXNfY29uc3Rl
eHByKGxlbiksIFwKKwkJX19idWlsdGluX21lbWNweSh0bywgZnJvbSwgbGVuKSwgXAorCQlfX3Jl
cF9tb3ZzX21lbWNweSh0bywgZnJvbSwgbGVuKSkKKworI2RlZmluZSBtZW1jcHkgX19idWlsdGlu
X21lbWNweQorCiAjZGVmaW5lIF9fSEFWRV9BUkNIX01FTVNFVAogdm9pZCAqbWVtc2V0KHZvaWQg
KnMsIGludCBjLCBzaXplX3Qgbik7CiB2b2lkICpfX21lbXNldCh2b2lkICpzLCBpbnQgYywgc2l6
ZV90IG4pOwpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9saW51eC9mb3J0aWZ5LXN0cmluZy5oIGIvaW5j
bHVkZS9saW51eC9mb3J0aWZ5LXN0cmluZy5oCmluZGV4IGRhNTFhODNiMjgyOS4uY2I3NzhmNjhm
NTM3IDEwMDY0NAotLS0gYS9pbmNsdWRlL2xpbnV4L2ZvcnRpZnktc3RyaW5nLmgKKysrIGIvaW5j
bHVkZS9saW51eC9mb3J0aWZ5LXN0cmluZy5oCkBAIC02OTAsNiArNjkwLDcgQEAgX19GT1JUSUZZ
X0lOTElORSBib29sIGZvcnRpZnlfbWVtY3B5X2NoayhfX2tlcm5lbF9zaXplX3Qgc2l6ZSwKICAq
IF9fc3RydWN0X3NpemUoKSB2cyBfX21lbWJlcl9zaXplKCkgbXVzdCBiZSBjYXB0dXJlZCBoZXJl
IHRvIGF2b2lkCiAgKiBldmFsdWF0aW5nIGFyZ3VtZW50IHNpZGUtZWZmZWN0cyBmdXJ0aGVyIGlu
dG8gdGhlIG1hY3JvIGxheWVycy4KICAqLworI3VuZGVmIG1lbWNweQogI2RlZmluZSBtZW1jcHko
cCwgcSwgcykgIF9fZm9ydGlmeV9tZW1jcHlfY2hrKHAsIHEsIHMsCQkJXAogCQlfX3N0cnVjdF9z
aXplKHApLCBfX3N0cnVjdF9zaXplKHEpLAkJCVwKIAkJX19tZW1iZXJfc2l6ZShwKSwgX19tZW1i
ZXJfc2l6ZShxKSwJCQlcCg==
--000000000000059111060a3536ba--