Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3504445imm; Sun, 10 Jun 2018 18:31:06 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKmBhEq3/ivRlG8PGKo3mB01EwHUYnbjbH9FMHhK4CJm8l22K9mZKKvWTpP+1DTG1V14rmE X-Received: by 2002:a62:5991:: with SMTP id k17-v6mr5304371pfj.94.1528680666044; Sun, 10 Jun 2018 18:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528680666; cv=none; d=google.com; s=arc-20160816; b=m3r8YwPwmo0Hln47lC6o9j1VR7oQ7OBoAwKidRW7P5PcFWFhvpz6yQV9HRTgDbGusi NtjXe/eewCcv6evLb0FX3PvUckuL8NOBNQIuBlLwiudAi89ALK+NgDSyA8Q6fwbpSVm0 AiaoafS4F3x2hr0Y8HWCWdIbJl3xZAvWcvtFfHJwpIEgOheSGXu9sDHbO8Y2IZLUM9qE OpTT0+k6CYEgIhKQDwZUYo1g3uTExx7XR5jDf2igwYPkdjNE2GGWbeaBbQFBMxDqoF8F VqI67dvg3Pnsu8/hKidqULx/iVDb7AoLaZ5LUHwY3cdIh9phyYOI2d7v1puFxQLnHhqa 5UGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:arc-authentication-results; bh=9J8OGX460LfuvIyjVfwPvGO/AvV9PirbOC1AzpYwBLY=; b=Mtl3CwFk/D3gAnsE8EuR3tftRj+CivyUp31EPAZfwG/wvYWtFbUNRlaaP7k9IZ9vUt 5ZiuAqGVAIrLCSXZbFvkbcplmheAh610ePla2MJZEecRMjCEG3OhOBvhJ9OMru/W+vvE P2J8/m8kAYhnna2cRPNYzHMjoXvi0wWxL9Kyv5yfUqvXHMiBISCYophvkuQLXzg+tzgh ocC7lMyqNJSMxNIwDS/bH05V9ihVR2T7CSrfvRVkhnZPxzIltxEPf2EhKFcviBpjGUcz /sollo1UIDkjS7K7MqUdhAaiAZ2X4euqVgNxX7c/ZjwHf0CZwidjh4yk29UpmLsHY9K8 zO7g== 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 q1-v6si27626390pgs.441.2018.06.10.18.30.50; Sun, 10 Jun 2018 18:31:06 -0700 (PDT) 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 S932092AbeFKBaZ convert rfc822-to-8bit (ORCPT + 99 others); Sun, 10 Jun 2018 21:30:25 -0400 Received: from terminus.zytor.com ([198.137.202.136]:45153 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753714AbeFKBaY (ORCPT ); Sun, 10 Jun 2018 21:30:24 -0400 Received: from wld62.hos.anvin.org (c-24-5-245-234.hsd1.ca.comcast.net [24.5.245.234] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w5B1U2nd3570021 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 10 Jun 2018 18:30:02 -0700 Date: Sun, 10 Jun 2018 18:29:54 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20180610141911.52948-10-namit@vmware.com> References: <20180610141911.52948-1-namit@vmware.com> <20180610141911.52948-10-namit@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly To: Nadav Amit , linux-kernel@vger.kernel.org, x86@kernel.org CC: Thomas Gleixner , Ingo Molnar , Greg Kroah-Hartman , Kate Stewart , Philippe Ombredanne From: hpa@zytor.com Message-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote: >Use assembly macros for jump-labels and call them from inline assembly. >This not only makes the code more readable, but also improves >compilation decision, specifically inline decisions which GCC base on >the number of new lines in inline assembly. > >As a result the code size is slightly increased. > > text data bss dec hex filename >18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before >18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128) > >And functions such as intel_pstate_adjust_policy_max(), >kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined. > >Cc: Thomas Gleixner >Cc: Ingo Molnar >Cc: "H. Peter Anvin" >Cc: x86@kernel.org >Cc: Greg Kroah-Hartman >Cc: Kate Stewart >Cc: Philippe Ombredanne > >Signed-off-by: Nadav Amit >--- > arch/x86/include/asm/jump_label.h | 65 ++++++++++++++++++------------- > arch/x86/kernel/macros.S | 1 + > 2 files changed, 39 insertions(+), 27 deletions(-) > >diff --git a/arch/x86/include/asm/jump_label.h >b/arch/x86/include/asm/jump_label.h >index 8c0de4282659..ea0633a41122 100644 >--- a/arch/x86/include/asm/jump_label.h >+++ b/arch/x86/include/asm/jump_label.h >@@ -2,19 +2,6 @@ > #ifndef _ASM_X86_JUMP_LABEL_H > #define _ASM_X86_JUMP_LABEL_H > >-#ifndef HAVE_JUMP_LABEL >-/* >- * For better or for worse, if jump labels (the gcc extension) are >missing, >- * then the entire static branch patching infrastructure is compiled >out. >- * If that happens, the code in here will malfunction. Raise a >compiler >- * error instead. >- * >- * In theory, jump labels and the static branch patching >infrastructure >- * could be decoupled to fix this. >- */ >-#error asm/jump_label.h included on a non-jump-label kernel >-#endif >- > #define JUMP_LABEL_NOP_SIZE 5 > > #ifdef CONFIG_X86_64 >@@ -28,18 +15,27 @@ > > #ifndef __ASSEMBLY__ > >+#ifndef HAVE_JUMP_LABEL >+/* >+ * For better or for worse, if jump labels (the gcc extension) are >missing, >+ * then the entire static branch patching infrastructure is compiled >out. >+ * If that happens, the code in here will malfunction. Raise a >compiler >+ * error instead. >+ * >+ * In theory, jump labels and the static branch patching >infrastructure >+ * could be decoupled to fix this. >+ */ >+#error asm/jump_label.h included on a non-jump-label kernel >+#endif >+ > #include > #include > >static __always_inline bool arch_static_branch(struct static_key *key, >bool branch) > { >- asm_volatile_goto("1:" >- ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t" >- ".pushsection __jump_table, \"aw\" \n\t" >- _ASM_ALIGN "\n\t" >- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t" >- ".popsection \n\t" >- : : "i" (key), "i" (branch) : : l_yes); >+ asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\" >" >+ "branch=\"%c1\"" >+ : : "i" (key), "i" (branch) : : l_yes); > > return false; > l_yes: >@@ -48,13 +44,8 @@ static __always_inline bool >arch_static_branch(struct static_key *key, bool bran > >static __always_inline bool arch_static_branch_jump(struct static_key >*key, bool branch) > { >- asm_volatile_goto("1:" >- ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t" >- "2:\n\t" >- ".pushsection __jump_table, \"aw\" \n\t" >- _ASM_ALIGN "\n\t" >- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t" >- ".popsection \n\t" >+ asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\" >key=\"%c0\" " >+ "branch=\"%c1\"" > : : "i" (key), "i" (branch) : : l_yes); > > return false; >@@ -108,6 +99,26 @@ struct jump_entry { > .popsection > .endm > >+.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req >+1: >+ .byte STATIC_KEY_INIT_NOP >+ .pushsection __jump_table, "aw" >+ _ASM_ALIGN >+ _ASM_PTR 1b, \l_yes, \key + \branch >+ .popsection >+.endm >+ >+.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req >+1: >+ .byte 0xe9 >+ .long \l_yes - 2f >+2: >+ .pushsection __jump_table, "aw" >+ _ASM_ALIGN >+ _ASM_PTR 1b, \l_yes, \key + \branch >+ .popsection >+.endm >+ > #endif /* __ASSEMBLY__ */ > > #endif >diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S >index bf8b9c93e255..161c95059044 100644 >--- a/arch/x86/kernel/macros.S >+++ b/arch/x86/kernel/macros.S >@@ -13,3 +13,4 @@ > #include > #include > #include >+#include If the code size increases, do you have any metrics for improvement? That being said, I do like the readability improvements and the ability to use gas macros in assembly as opposed to cpp macros wrapped in different ways for C and assembly. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.