Received: by 10.223.176.5 with SMTP id f5csp1272955wra; Fri, 2 Feb 2018 14:26:37 -0800 (PST) X-Google-Smtp-Source: AH8x227eGkET6hIadwP7kzIFZBas2n9JwtKtxGxl7PkNIpeZBVtJkiz0S9J4qv3V9gU26kZC7JrF X-Received: by 10.98.61.71 with SMTP id k68mr3327395pfa.133.1517610397641; Fri, 02 Feb 2018 14:26:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517610397; cv=none; d=google.com; s=arc-20160816; b=LagNXnKKDqONWnMCzUaeRcleghjwDOafDRYg0YNhkec6MMM8fKjOvtSuYzi00GT6r4 afCuWNquyRsuRIirxgp0zl+gDLk10L9A2QFOQW12l9ByNmirW97Na+O7qfWGZr2t/HWL 62aBK0KLDT8OIo1h3/t3GXTc6p2G6eBKkB0BJswxeWQMEaOSD+PH4pdqbSj5o+24lrSv ba6zmFlLydd9nHo2usbWwNUMKjY7fF++gmexj3Bwfm9VwN32WBYVHpQTrXLsMiaDxK/M sOVNCeWAcm2bkkg5irSZzZ3yteZFWOJlfZrGBYKbAPlJwheaXYqHcOp2JgON5a8GtKaX Olcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=yR5CAaLAxA1fF/xshL9xH3Kcpdf9Rvl/bI0EIq7zHJ0=; b=v9t6xcQLeTqZiC4neSAxdq2H6Nmx985gSMsALQE1t1PVB7HLRZ0z1k31TvnGiGTGAH 6Q8vxXcPbDc93VluRKsaqFIWRnJgRW4FJApkc4dvr+CTtBGjBIiCN0CjvepDQTV/YbPt jMObvT9NZFP27oPLyiJKy6SPU0/FHXNLPTkQSZS930XTtMuX01hBcr5E7Z5HY2cwmFU5 3IsZWju8x2Mt7usHiAe71swMjyYS6LAR4BBm78bnU4yVYm6jSiMBI5nJX3aCZIzqlTWa XEViKi+/b5emN1IEqWf6fKP8TaQjxPM1XtY4CELK61LlJsJ0UfTC2u20k3TILG+VsCnS 4L1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a185si2061988pgc.69.2018.02.02.14.25.50; Fri, 02 Feb 2018 14:26:37 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752111AbeBBVYU (ORCPT + 99 others); Fri, 2 Feb 2018 16:24:20 -0500 Received: from www.llwyncelyn.cymru ([82.70.14.225]:37072 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751557AbeBBVYQ (ORCPT ); Fri, 2 Feb 2018 16:24:16 -0500 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w12LNYSZ028413; Fri, 2 Feb 2018 21:23:34 GMT Date: Fri, 2 Feb 2018 21:23:33 +0000 From: Alan Cox To: David Woodhouse Cc: Linus Torvalds , Thomas Gleixner , KarimAllah Ahmed , sironi@amazon.de, the arch/x86 maintainers , KVM list , Paolo Bonzini , Linux Kernel Mailing List , Borislav Petkov , Peter Zijlstra Subject: Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range() Message-ID: <20180202212321.5186c13c@alans-desktop> In-Reply-To: <1517599033.31953.71.camel@infradead.org> References: <1517583559-424-1-git-send-email-dwmw@amazon.co.uk> <1517599033.31953.71.camel@infradead.org> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Either way, that does look like a reasonable answer. I had looked at > the various one-line wrappers around slot_handle_level_range() and > thought "hm, those should be inline", but I hadn't made the next step > and pondered putting the whole thing inline. We'll give it a spin and > work out where the next performance bottleneck is. Thanks. In addition the problem with switch() is that gcc might decide in some cases that the best way to implement your switch is an indirect call from a lookup table. For the simple case how about wrapping the if into call_likely(foo->bar, usualfunction, args) as a companion to foo->bar(args) that can resolve to nothing special on architectures that don't need it, an if/else case on platforms with spectre, and potentially clever stuff on any platform where you can beat the compiler by knowing probabilities it can't infer ? Alan