From patchwork Fri Feb 2 19:10:19 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Torvalds X-Patchwork-Id: 10198035 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6F79E60388 for ; Fri, 2 Feb 2018 19:10:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5F3FF28F59 for ; Fri, 2 Feb 2018 19:10:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 53C7328F5B; Fri, 2 Feb 2018 19:10:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ED11528F59 for ; Fri, 2 Feb 2018 19:10:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752627AbeBBTKX (ORCPT ); Fri, 2 Feb 2018 14:10:23 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:33619 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751958AbeBBTKU (ORCPT ); Fri, 2 Feb 2018 14:10:20 -0500 Received: by mail-it0-f68.google.com with SMTP id u12-v6so2600268ite.0; Fri, 02 Feb 2018 11:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9rH31yFVHYdaWLtUZVh8M+NdFnPoPOI4g/C4wefVNK8=; b=s841umX2Q8yU0vHcJocSaN/MpmAIp3zyCKszxvBdSNlb5kmzHYGPRel1jPa2wGeLaO +GklMATCUllGca1mjtuftK1mBDSPrkP/QDBpHUeYGaSc2GsWbb/1GkRUliurFxZKtXgi yI3IVtDcNqaS3ecClpkAeSrr1GyIjsod65p0BGDJsrISB3xC6dRXqrZKosVybb+uFbIY zpUqb8Vi3ivxewgceJquDRoD/P3Ts6LQOZfi0Q71Y1yYu9SRBmP2lyziDjLL5KslhgTS UrMMewsqNzywxjb1FLSHpKe7P/2BkYY1Jd/HMp/8bC4YTSHa4uOT80kLklg5YU32m+hg eQrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9rH31yFVHYdaWLtUZVh8M+NdFnPoPOI4g/C4wefVNK8=; b=E6In0VbYaxWDdx7WqHnxK4ExrljpwLN04y8YLwMkH6FIFxUOFlJ5kydNYUlbd+MRUi YtPRdi0KrFyD8p/CwQqBZ05RHtlwh62vdiSOAmAvhD9HsLnEZ5aGkqBZqeIvi2oEz98F TBPOpn51YOkZia9vnuycOUR3SIHArETlwd8sgRLTkcahX6nxhl0R/rSYaMwBsLuj5ReD ET23qRnHCSJCTuPtxbXiBfYL8ZAwGbcwp25E+VUJICcs1ay6MDfBj1KFTPSRwRmu5gSP sRYzxobX/TE7q6FdmlS8tgGJNygr3bmsjbvcNiDe1UD2wMziLbshMomNDeH+72gMa9NV N5dA== X-Gm-Message-State: AKwxyte2nurWNDmtbS02PDyPrOowfS7kbrySNsiZJkrPhZExNsovWVPy BYgZnZTD3J90SDq7LZ/MsQgHGIx8OndFDCbvEqY= X-Google-Smtp-Source: AH8x225IoNEEqR9VRDuFo7Hj1J1v5FE5OMLXtnr4CBDY80J98q4eKBCdDdXLz0Y2V0OX1a0cGfxqMiAVlO01ZIMDm9g= X-Received: by 10.36.47.5 with SMTP id j5mr45133787itj.123.1517598620041; Fri, 02 Feb 2018 11:10:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.196 with HTTP; Fri, 2 Feb 2018 11:10:19 -0800 (PST) In-Reply-To: References: <1517583559-424-1-git-send-email-dwmw@amazon.co.uk> From: Linus Torvalds Date: Fri, 2 Feb 2018 11:10:19 -0800 X-Google-Sender-Auth: 6SK_2tR_S35z2EFi0xn5IwfesRs Message-ID: Subject: Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range() To: David Woodhouse Cc: Thomas Gleixner , KarimAllah Ahmed , sironi@amazon.de, "the arch/x86 maintainers" , KVM list , Paolo Bonzini , Linux Kernel Mailing List , Borislav Petkov , Peter Zijlstra Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Fri, Feb 2, 2018 at 10:50 AM, Linus Torvalds wrote: > > Will it make for bigger code? Yes. But probably not really all *that* > much bigger, because of how it also will allow the compiler to > simplify some things. Actually, testing this with my fairly minimal config, it actually makes for *smaller* code to inline those things. That may be a quirk of my configuration, or maybe I screwed something else up, but: [torvalds@i7 linux]$ size ~/mmu.o arch/x86/kvm/mmu.o text data bss dec hex filename 85587 9310 120 95017 17329 /home/torvalds/mmu.o 85531 9310 120 94961 172f1 arch/x86/kvm/mmu.o so the attached patch actually shrank things down by about 50 bytes because of the code simplification. Of course, I have been known to screw up retpoline testing in the past, so my numbers are suspect ;). Somebody should double-check me. Linus arch/x86/kvm/mmu.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 2b8eb4da4d08..b9f0de6e309b 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -5058,7 +5058,7 @@ void kvm_mmu_uninit_vm(struct kvm *kvm) typedef bool (*slot_level_handler) (struct kvm *kvm, struct kvm_rmap_head *rmap_head); /* The caller should hold mmu-lock before calling this function. */ -static bool +static bool __always_inline slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot, slot_level_handler fn, int start_level, int end_level, gfn_t start_gfn, gfn_t end_gfn, bool lock_flush_tlb) @@ -5088,7 +5088,7 @@ slot_handle_level_range(struct kvm *kvm, struct kvm_memory_slot *memslot, return flush; } -static bool +static bool __always_inline slot_handle_level(struct kvm *kvm, struct kvm_memory_slot *memslot, slot_level_handler fn, int start_level, int end_level, bool lock_flush_tlb) @@ -5099,7 +5099,7 @@ slot_handle_level(struct kvm *kvm, struct kvm_memory_slot *memslot, lock_flush_tlb); } -static bool +static bool __always_inline slot_handle_all_level(struct kvm *kvm, struct kvm_memory_slot *memslot, slot_level_handler fn, bool lock_flush_tlb) { @@ -5107,7 +5107,7 @@ slot_handle_all_level(struct kvm *kvm, struct kvm_memory_slot *memslot, PT_MAX_HUGEPAGE_LEVEL, lock_flush_tlb); } -static bool +static bool __always_inline slot_handle_large_level(struct kvm *kvm, struct kvm_memory_slot *memslot, slot_level_handler fn, bool lock_flush_tlb) { @@ -5115,7 +5115,7 @@ slot_handle_large_level(struct kvm *kvm, struct kvm_memory_slot *memslot, PT_MAX_HUGEPAGE_LEVEL, lock_flush_tlb); } -static bool +static bool __always_inline slot_handle_leaf(struct kvm *kvm, struct kvm_memory_slot *memslot, slot_level_handler fn, bool lock_flush_tlb) {