[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A7D88101-837A-4FD2-B397-019D1845A418@vmware.com>
Date: Mon, 31 Dec 2018 19:53:06 +0000
From: Nadav Amit <namit@...are.com>
To: Andy Lutomirski <luto@...nel.org>
CC: Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Edward Cree <ecree@...arflare.com>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Borislav Petkov <bp@...en8.de>,
David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion
> On Dec 31, 2018, at 11:51 AM, Andy Lutomirski <luto@...nel.org> wrote:
>
> On Sun, Dec 30, 2018 at 11:20 PM Nadav Amit <namit@...are.com> wrote:
>> This is a revised version of optpolines (formerly named retpolines) for
>> dynamic indirect branch promotion in order to reduce retpoline overheads
>> [1].
>
> Some of your changelogs still call them "relpolines".
>
> I have a crazy suggestion: maybe don't give them a cute name at all?
> Where it's actually necessary to name them (like in a config option),
> use a description like CONFIG_DYNAMIC_DEVIRTUALIZATION or
> CONFIG_PATCH_INDIRECT_CALLS or something.
I’m totally fine with that (don’t turn me into a "marketing” guy). It was
just a way to refer to the mechanism. I need more feedback about the more
fundamental issues to go on.
Powered by blists - more mailing lists