[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CE9C4B9C-3B11-45D0-812A-F074D687084D@vmware.com>
Date: Thu, 4 Oct 2018 16:30:57 +0000
From: Nadav Amit <namit@...are.com>
To: Andy Lutomirski <luto@...capital.net>
CC: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
David Woodhouse <dwmw@...zon.co.uk>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [RFC] x86/cpu_entry_area: move part of it back to fixmap
at 7:11 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
>
> On Oct 3, 2018, at 9:59 PM, Nadav Amit <namit@...are.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 branch
>> 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 against -tip? If it’s 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’s what I get for not following lkml. Very nice discussion.
Based on it, I may be able to do an additional micro-optimizations or
two. Let me give it a try.
Powered by blists - more mailing lists