[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwwa_A3RfodonHVDz+2xZ0+x+=MRPCVDqTkaG96SV5ZoQ@mail.gmail.com>
Date: Fri, 2 Dec 2016 11:35:58 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Borislav Petkov <bp@...en8.de>, Borislav Petkov <bp@...nel.org>,
Andy Lutomirski <luto@...nel.org>, Peter Anvin <hpa@...or.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Brian Gerst <brgerst@...il.com>,
Matthew Whitehead <tedheadster@...il.com>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation
On Fri, Dec 2, 2016 at 11:30 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> How's this?
Looks ok. I do think that
> I suppose it could be an unconditional IRET-to-self, but that's a good
> deal slower and not a whole lot simpler. Although if we start doing
> it right, performance won't really matter here.
Considering you already got the iret-to-self wrong in the first
version, I really like the "one single unconditional version" so that
everybody tests that _one_ thing and there isn't anything subtle going
on.
Hmm?
And yes, if it turns out that performance matters, we almost certainly
are doing something really wrong, and we shouldn't be using that
sync_core() thing in that place anyway.
Linus
Powered by blists - more mailing lists