Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755189AbcLBSLo (ORCPT ); Fri, 2 Dec 2016 13:11:44 -0500 Received: from mail-io0-f193.google.com ([209.85.223.193]:34960 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbcLBSLm (ORCPT ); Fri, 2 Dec 2016 13:11:42 -0500 MIME-Version: 1.0 In-Reply-To: References: <0a21157c2233ba7d0781bbf07866b3f2d7e7c25d.1480638597.git.luto@kernel.org> From: Linus Torvalds Date: Fri, 2 Dec 2016 09:53:52 -0800 X-Google-Sender-Auth: GXfaagUS6F6QBGdYJyHLRGeRCas Message-ID: Subject: Re: [PATCH v2 5/6] x86/xen: Add a Xen-specific sync_core() implementation To: Andy Lutomirski Cc: Peter Anvin , "the arch/x86 maintainers" , One Thousand Gnomes , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Matthew Whitehead , Henrique de Moraes Holschuh , Peter Zijlstra , Andrew Cooper Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 890 Lines: 22 On Fri, Dec 2, 2016 at 9:38 AM, Andy Lutomirski wrote: > > apply_alternatives, unfortunately. It's performance-critical because > it's intensely stupid and does sync_core() for every single patch. > Fixing that would be nice, too. So looking at text_poke_early(), that's very much a case that really shouldn't need any "sync_core()" at all as far as I can tell. Only the current CPU is running, and for local CPU I$ coherence all you need is a jump instruction, and even that is only on really old CPU's. From the PPro onwards (maybe even Pentium?) the I$ is entirely serialized as long as you change the data using the same linear address. So at most, that function could mark itsel f"noinline" just to guarantee that it will cause a control flow change before returning. The sync_core() seems entirely bogus. Same goes for optimize_nops() too. Linus