Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] x86: only use ERMS for user copies for larger sizes
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <CAHk-=wjrdrZW5VgnKXqdayafYmQC2HBEA4kzMWYTyaj5jgURdA@mail.gmail.com>
Date:   Fri, 23 Nov 2018 11:39:29 -0700
Cc:     David.Laight@aculab.com, Andrew Lutomirski <luto@kernel.org>,
        dvlasenk@redhat.com, Jens Axboe <axboe@kernel.dk>,
        Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, bp@alien8.de,
        Peter Anvin <hpa@zytor.com>,
        the arch/x86 maintainers <x86@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>, brgerst@gmail.com,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        pabeni@redhat.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <C74CD745-0E6D-410C-B942-416AF365B492@amacapital.net>
References: <02bfc577-32a5-66be-64bf-d476b7d447d2@kernel.dk> <20181121063609.GA109082@gmail.com> <48e27a3a-2bb2-ff41-3512-8aeb3fd59e57@kernel.dk> <26eff539-7de7-784c-0c88-f1d30753299d@redhat.com> <7ea44458b90b4d41a08ba9012818d273@AcuMS.aculab.com> <CAHk-=wjLNuNpHRfuVTb6awstC9OOmSb3S8aP51ufep-Th4dXKw@mail.gmail.com> <CALCETrW=hMZLUM_nPEEgUW9x9Bmhm2LZ6ZRDiRRguxVT=-_BWA@mail.gmail.com> <CAHk-=wiEUVpSU-GxpKDvN9wnH2yDxkJgE7Vqh46A+fmnvhubyw@mail.gmail.com> <cd11d9423c8b46ecbf97753f8317c294@AcuMS.aculab.com> <64fd67993af04579b5262c270a7a4694@AcuMS.aculab.com> <CAHk-=wj9DA-mH8jahuEPUWxO4EgbCcPRgdOJAQD58DBtCCrHcQ@mail.gmail.com> <CAHk-=wjrdrZW5VgnKXqdayafYmQC2HBEA4kzMWYTyaj5jgURdA@mail.gmail.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Nov 23, 2018, at 10:42 AM, Linus Torvalds <torvalds@linux-foundation.or=
g> wrote:
>=20
> On Fri, Nov 23, 2018 at 8:36 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>=20
>> Let me write a generic routine in lib/iomap_copy.c (which already does
>> the "user specifies chunk size" cases), and hook it up for x86.
>=20
> Something like this?
>=20
> ENTIRELY UNTESTED! It might not compile. Seriously. And if it does
> compile, it might not work.
>=20
> And this doesn't actually do the memset_io() function at all, just the
> memcpy ones.
>=20
> Finally, it's worth noting that on x86, we have this:
>=20
>  /*
>   * override generic version in lib/iomap_copy.c
>   */
>  ENTRY(__iowrite32_copy)
>          movl %edx,%ecx
>          rep movsd
>          ret
>  ENDPROC(__iowrite32_copy)
>=20
> because back in 2006, we did this:
>=20
>    [PATCH] Add faster __iowrite32_copy routine for x86_64
>=20
>    This assembly version is measurably faster than the generic version in
>    lib/iomap_copy.c.
>=20
> which actually implies that "rep movsd" is faster than doing
> __raw_writel() by hand.
>=20
> So it is possible that this should all be arch-specific code rather
> than that butt-ugly "generic" code I wrote in this patch.
>=20
> End result: I'm not really all that  happy about this patch, but it's
> perhaps worth testing, and it's definitely worth discussing. Because
> our current memcpy_{to,from}io() is truly broken garbage.
>=20
>                  =20

What is memcpy_to_io even supposed to do?  I=E2=80=99m guessing it=E2=80=99s=
 defined as something like =E2=80=9Ccopy this data to IO space using at most=
 long-sized writes, all aligned, and writing each byte exactly once, in orde=
r.=E2=80=9D  That sounds... dubiously useful.  I could see a function that w=
rites to aligned memory in specified-sized chunks.  And I can see a use for a=
 function to just write it in whatever size chunks the architecture thinks i=
s fastest, and *that* should probably use MOVDIR64B.

Or is there some subtlety I=E2=80=99m missing?=