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;
MIME-Version: 1.0
References: <20181004045948.129142-1-namit@vmware.com> <72B0B378-9515-47C4-8937-9F1E823DD236@amacapital.net>
 <CE9C4B9C-3B11-45D0-812A-F074D687084D@vmware.com>
In-Reply-To: <CE9C4B9C-3B11-45D0-812A-F074D687084D@vmware.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Thu, 4 Oct 2018 10:02:48 -0700
Message-ID: <CALCETrVkE9eV0b2-wfq4Y9iK+YVJ4JBL7_rk_A8-7EhtuBbncA@mail.gmail.com>
Subject: Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap
To:     Nadav Amit <namit@vmware.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        "Woodhouse, David" <dwmw@amazon.co.uk>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Lutomirski <luto@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 4, 2018 at 9:31 AM Nadav Amit <namit@vmware.com> wrote:
>
> at 7:11 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> >
> >
> > On Oct 3, 2018, at 9:59 PM, Nadav Amit <namit@vmware.com> wrote:
> >
> >> This RFC proposes to return part of the entry-area back to the fixmap =
to
> >> improve system-call performance. Currently, since the entry-area is
> >> mapped far (more than 2GB) away from the kernel text, an indirect bran=
ch
> >> is needed to jump from the trampoline into the kernel. Due to Spectre
> >> v2, vulnerable CPUs need to use a retpoline, which introduces an
> >> overhead of >20 cycles.
> >
> > That retpoline is gone in -tip. Can you see how your code stacks up aga=
inst -tip?  If it=E2=80=99s enough of a win to justify the added complexity=
, we can try it.
> >
> > You can see some pros and cons in the changelog:
> >
> > https://git.kernel.org/tip/bf904d2762ee6fc1e4acfcb0772bbfb4a27ad8a6
>
> Err.. That=E2=80=99s what I get for not following lkml. Very nice discuss=
ion.
> Based on it, I may be able to do an additional micro-optimizations or
> two. Let me give it a try.
>

I think you should at least try to benchmark your code against mine,
since you more or less implemented the alternative I suggested. :)