Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
MIME-Version: 1.0
References: <20231015202523.189168-1-ubizjak@gmail.com> <20231015202523.189168-3-ubizjak@gmail.com>
 <ZS0bLvcC46tHjM/G@gmail.com> <ZS2PIzzffqflnVoY@google.com>
In-Reply-To: <ZS2PIzzffqflnVoY@google.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 16 Oct 2023 12:54:35 -0700
Message-ID: <CAHk-=wj-MFtUhhFUzv1_8zrpkRFWY5vG72WzrG-xAkJB+1S1hQ@mail.gmail.com>
Subject: Re: [PATCH -tip 3/3] x86/percpu: *NOT FOR MERGE* Implement
 arch_raw_cpu_ptr() with RDGSBASE
To:     Sean Christopherson <seanjc@google.com>
Cc:     Ingo Molnar <mingo@kernel.org>, Uros Bizjak <ubizjak@gmail.com>,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        Nadav Amit <namit@vmware.com>,
        Andy Lutomirski <luto@kernel.org>,
        Brian Gerst <brgerst@gmail.com>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Borislav Petkov <bp@alien8.de>
Content-Type: multipart/mixed; boundary="0000000000009a2b780607dac7a8"
Precedence: bulk

--0000000000009a2b780607dac7a8
Content-Type: text/plain; charset="UTF-8"

On Mon, 16 Oct 2023 at 12:29, Sean Christopherson <seanjc@google.com> wrote:
>
> > Are we certain that ucode on modern x86 CPUs check CR4 for every affected
> > instruction?
>
> Not certain at all.  I agree the CR4.FSGSBASE thing could be a complete non-issue
> and was just me speculating.

Note that my timings on two fairly different arches do put the cost of
'rdgsbase' at 2 cycles, so it's not microcoded in the sense of jumping
off to some microcode sequence that has a noticeable overhead.

So it's almost certainly what Intel calls a "complex decoder" case
that generates up to 4 uops inline and only decodes in the first
decode slot.

One of the uops could easily be a cr4 check, that's not an uncommon
thing for those kinds of instructions.

If somebody wants to try my truly atrocious test program on other
machines, go right ahead. It's attached. I'm not proud of it. It's a
hack.

Do something like this:

    $ gcc -O2 t.c
    $ ./a.out
      "nop"=0l: 0.380925
      "nop"=0l: 0.380640
      "nop"=0l: 0.380373
      "mov %1,%0":"=r"(base):"m"(zero)=0l: 0.787984
      "rdgsbase %0":"=r"(base)=0l: 2.626625

and you'll see that a no-op takes about a third of a cycle on my Zen 2
core (according to this truly stupid benchmark). With some small
overhead.

And a "mov memory to register" shows up as ~3/4 cycle, but it's really
probably that the core can do two of them per cycle, and then the
chain of adds (see how that benchmark makes sure the result is "used")
adds some more overhead etc.

And the 'rdgsbase' is about two cycles, and presumably is fully
serialized, so all the loop overhead and adding results then shows up
as that extra .6 of a cycle on average.

But doing cycle estimations on OoO machines is "guess rough patterns",
so take all the above with a big pinch of salt. And feel free to test
it on other cores than the ones I did (Intel Skylake and and AMD Zen
2). You migth want to put your machine into "performance" mode or
other things to actually make it run at the highest frequency to get
more repeatable numbers.

The Skylake core does better on the nops (I think Intel gets rid of
them earlier in the decode stages and they basically disappear in the
uop cache), and can do three loads per cycle. So rdgsbase looks
relatively slower on my Skylake at about 3 cycles per op, but when you
look at an individual instruction, that's a fairly artificial thing.
You don't run these things in the uop cache in reality.

              Linus

--0000000000009a2b780607dac7a8
Content-Type: text/x-c-code; charset="US-ASCII"; name="t.c"
Content-Disposition: attachment; filename="t.c"
Content-Transfer-Encoding: base64
Content-ID: <f_lntaw81r0>
X-Attachment-Id: f_lntaw81r0

I2luY2x1ZGUgPHN0ZGlvLmg+CgojZGVmaW5lIE5SIDEwMDAwMDAwMAoKI2RlZmluZSBMT09QKHgp
IGZvcihpbnQgaSA9IDA7IGkgPCBOUi8xNjsgaSsrKSBkbyB7IFwKCWFzbSB2b2xhdGlsZSh4KTsg
c3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xh
dGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwK
CWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9
IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4
KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2
b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7
IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3Vt
ICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGls
ZSh4KTsgc3VtICs9IGJhc2U7IFwKCWFzbSB2b2xhdGlsZSh4KTsgc3VtICs9IGJhc2U7IFwKfSB3
aGlsZSAoMCkKCnN0YXRpYyBpbmxpbmUgdW5zaWduZWQgaW50IHJkdHNjKHZvaWQpCnsKCXVuc2ln
bmVkIGludCBhLGQ7Cglhc20gdm9sYXRpbGUoInJkdHNjIjoiPWEiKGEpLCI9ZCIoZCk6OiJtZW1v
cnkiKTsKCXJldHVybiBhOwp9CgojZGVmaW5lIFRFU1QoeCkgZG8geyBcCgl1bnNpZ25lZCBpbnQg
cyA9IHJkdHNjKCk7IFwKCUxPT1AoeCk7IFwKCXMgPSByZHRzYygpLXM7IFwKCWZwcmludGYoc3Rk
ZXJyLCAiICAiICN4ICI9JXVsOiAlZlxuIiwgc3VtLCBzIC8gKGRvdWJsZSlOUik7IFwKfSB3aGls
ZSAoMCkKCmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikKewoJdW5zaWduZWQgbG9uZyBi
YXNlID0gMCwgc3VtID0gMDsKCXVuc2lnbmVkIGxvbmcgemVybyA9IDA7CgoJVEVTVCgibm9wIik7
CglURVNUKCJub3AiKTsKCVRFU1QoIm5vcCIpOwoJVEVTVCgibW92ICUxLCUwIjoiPXIiKGJhc2Up
OiJtIih6ZXJvKSk7CglURVNUKCJyZGdzYmFzZSAlMCI6Ij1yIihiYXNlKSk7CglyZXR1cm4gMDsK
fQo=
--0000000000009a2b780607dac7a8--