Message ID | 20230109135828.879136-4-mark.rutland@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp2171028wrt; Mon, 9 Jan 2023 06:01:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXvwc9gn4cjP0p+7Ma7EwwgWzMCvF0YMMt48obH2P2Sn5cSBY+Vs629vIOjdLHsEDi4Qo361 X-Received: by 2002:a17:90a:ebc6:b0:226:5900:f2f4 with SMTP id cf6-20020a17090aebc600b002265900f2f4mr34849887pjb.4.1673272891999; Mon, 09 Jan 2023 06:01:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673272891; cv=none; d=google.com; s=arc-20160816; b=gV6r5aB9hBnwEerYEoWMeHr6c3zIOAAwG/Se8hjR6OQN94a+TzL14RZkeUC+vYTJ6Q +MkLWRyi6f6rr3YqYqbay/I+4AOvQffRAtll96E/5Kcqrvbims14NUAZJeL1lzMGAF7k 4vDq+264YMhv3QM20RYQqKQnOdyt7QV9jyOphjL4NVzC+Y6ZbhHbFnWmNEUdc8iIoHN+ cTHWj7CseSKEkHvs7Eb6r2yxt7YLp9vrtEyYRW1j5PxF8bZxKg6NZVBcJrGQkmPWoOLK pT/d6bx65R+ZoqZ9/+kKBBSgWqGdAkEAXXsTzHHQGOVJ4wXEnI+BImD2F7I+b3+82dk8 Nf2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=uS6ssPWGHEZJFSKX4hxjdcKxWoVnBVtrpoOuY5hYNNg=; b=C8xTiSxjmCgoWBpPUHZ6+69DKR9SnpZ9FfBFJ0peAAX320K/Inl5BewtnaftyQsH9n QSSozgDtzEpoP7RivOAx/Qd74QRV9MeoLcQ2GJCodTqnjIjmUPYazMCq1p1UvgZl3HUN FSp8rurwVcWS1IlkH+ilzpUQEqtYvu9wnFZzV6uDxC79ildh3XhZaIToqn7FKM+VuGYO mNINF+wZmzuPlOJAfZKsEhI+zgYY434ZkIxd2NDN1ZJAkIaLe5ewro/28VpG29HieUvV 1xb7iKN7vPRP1bBC2s8UipRaPVh2ky2DxKk39DKL/22AucrqEJcphDul9RjyfhenCgCu 4kOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mn20-20020a17090b189400b00226902ba17csi11609294pjb.109.2023.01.09.06.01.19; Mon, 09 Jan 2023 06:01:31 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237240AbjAIOAc (ORCPT <rfc822;274620705z@gmail.com> + 99 others); Mon, 9 Jan 2023 09:00:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237264AbjAIN6r (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 9 Jan 2023 08:58:47 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 419D3F6F; Mon, 9 Jan 2023 05:58:46 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 05F2B176B; Mon, 9 Jan 2023 05:59:28 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 308803F23F; Mon, 9 Jan 2023 05:58:44 -0800 (PST) From: Mark Rutland <mark.rutland@arm.com> To: linux-arm-kernel@lists.infradead.org Cc: catalin.marinas@arm.com, lenb@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, mhiramat@kernel.org, ndesaulniers@google.com, ojeda@kernel.org, peterz@infradead.org, rafael.j.wysocki@intel.com, revest@chromium.org, robert.moore@intel.com, rostedt@goodmis.org, will@kernel.org Subject: [PATCH 3/8] arm64: Extend support for CONFIG_FUNCTION_ALIGNMENT Date: Mon, 9 Jan 2023 13:58:23 +0000 Message-Id: <20230109135828.879136-4-mark.rutland@arm.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20230109135828.879136-1-mark.rutland@arm.com> References: <20230109135828.879136-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754553795916692472?= X-GMAIL-MSGID: =?utf-8?q?1754553795916692472?= |
Series |
arm64/ftrace: Add support for DYNAMIC_FTRACE_WITH_CALL_OPS
|
|
Commit Message
Mark Rutland
Jan. 9, 2023, 1:58 p.m. UTC
On arm64 we don't align assembly funciton in the same way as C
functions. This somewhat limits the utility of
CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B for testing.
Follow the example of x86, and align assembly functions in the same way
as C functions.
I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y,
building and booting a kernel, and looking for misaligned text symbols:
Before:
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
322
After:
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
115
The remaining unaligned text symbols are a combination of non-function labels
in assembly and early position-independent code which is built with '-Os'.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Florent Revest <revest@chromium.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/linkage.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
Comments
On Mon, Jan 09, 2023 at 01:58:23PM +0000, Mark Rutland wrote: > diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h > index 1436fa1cde24d..df18a3446ce82 100644 > --- a/arch/arm64/include/asm/linkage.h > +++ b/arch/arm64/include/asm/linkage.h > @@ -5,8 +5,14 @@ > #include <asm/assembler.h> > #endif > > -#define __ALIGN .align 2 > -#define __ALIGN_STR ".align 2" > +#if CONFIG_FUNCTION_ALIGNMENT > 0 > +#define ARM64_FUNCTION_ALIGNMENT CONFIG_FUNCTION_ALIGNMENT > +#else > +#define ARM64_FUNCTION_ALIGNMENT 4 > +#endif > + > +#define __ALIGN .balign ARM64_FUNCTION_ALIGNMENT > +#define __ALIGN_STR ".balign " #ARM64_FUNCTION_ALIGNMENT Isn't that much the same as having ARM64 select FUNCTION_ALIGNMENT_4B and simply removing all these lines and relying on the default behaviour?
On Tue, Jan 10, 2023 at 09:35:18PM +0100, Peter Zijlstra wrote: > On Mon, Jan 09, 2023 at 01:58:23PM +0000, Mark Rutland wrote: > > > diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h > > index 1436fa1cde24d..df18a3446ce82 100644 > > --- a/arch/arm64/include/asm/linkage.h > > +++ b/arch/arm64/include/asm/linkage.h > > @@ -5,8 +5,14 @@ > > #include <asm/assembler.h> > > #endif > > > > -#define __ALIGN .align 2 > > -#define __ALIGN_STR ".align 2" > > +#if CONFIG_FUNCTION_ALIGNMENT > 0 > > +#define ARM64_FUNCTION_ALIGNMENT CONFIG_FUNCTION_ALIGNMENT > > +#else > > +#define ARM64_FUNCTION_ALIGNMENT 4 > > +#endif > > + > > +#define __ALIGN .balign ARM64_FUNCTION_ALIGNMENT > > +#define __ALIGN_STR ".balign " #ARM64_FUNCTION_ALIGNMENT > > Isn't that much the same as having ARM64 select FUNCTION_ALIGNMENT_4B > and simply removing all these lines and relying on the default > behaviour? There's a proposal (with some rough performance claims) to select FUNCTION_ALIGNMENT_16B over at: https://lore.kernel.org/r/20221208053649.540891-1-almasrymina@google.com so we could just go with that? Will
On Tue, Jan 10, 2023 at 09:35:18PM +0100, Peter Zijlstra wrote: > On Mon, Jan 09, 2023 at 01:58:23PM +0000, Mark Rutland wrote: > > > diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h > > index 1436fa1cde24d..df18a3446ce82 100644 > > --- a/arch/arm64/include/asm/linkage.h > > +++ b/arch/arm64/include/asm/linkage.h > > @@ -5,8 +5,14 @@ > > #include <asm/assembler.h> > > #endif > > > > -#define __ALIGN .align 2 > > -#define __ALIGN_STR ".align 2" > > +#if CONFIG_FUNCTION_ALIGNMENT > 0 > > +#define ARM64_FUNCTION_ALIGNMENT CONFIG_FUNCTION_ALIGNMENT > > +#else > > +#define ARM64_FUNCTION_ALIGNMENT 4 > > +#endif > > + > > +#define __ALIGN .balign ARM64_FUNCTION_ALIGNMENT > > +#define __ALIGN_STR ".balign " #ARM64_FUNCTION_ALIGNMENT > > Isn't that much the same as having ARM64 select FUNCTION_ALIGNMENT_4B > and simply removing all these lines and relying on the default > behaviour? Yes, it is. I was focussed on obviously retaining the existing semantic by default, and I missed that was possible by selecting FUNCTION_ALIGNMENT_4B. Thanks, Mark.
On Tue, Jan 10, 2023 at 08:43:20PM +0000, Will Deacon wrote: > On Tue, Jan 10, 2023 at 09:35:18PM +0100, Peter Zijlstra wrote: > > On Mon, Jan 09, 2023 at 01:58:23PM +0000, Mark Rutland wrote: > > > > > diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h > > > index 1436fa1cde24d..df18a3446ce82 100644 > > > --- a/arch/arm64/include/asm/linkage.h > > > +++ b/arch/arm64/include/asm/linkage.h > > > @@ -5,8 +5,14 @@ > > > #include <asm/assembler.h> > > > #endif > > > > > > -#define __ALIGN .align 2 > > > -#define __ALIGN_STR ".align 2" > > > +#if CONFIG_FUNCTION_ALIGNMENT > 0 > > > +#define ARM64_FUNCTION_ALIGNMENT CONFIG_FUNCTION_ALIGNMENT > > > +#else > > > +#define ARM64_FUNCTION_ALIGNMENT 4 > > > +#endif > > > + > > > +#define __ALIGN .balign ARM64_FUNCTION_ALIGNMENT > > > +#define __ALIGN_STR ".balign " #ARM64_FUNCTION_ALIGNMENT > > > > Isn't that much the same as having ARM64 select FUNCTION_ALIGNMENT_4B > > and simply removing all these lines and relying on the default > > behaviour? > > There's a proposal (with some rough performance claims) to select > FUNCTION_ALIGNMENT_16B over at: > > https://lore.kernel.org/r/20221208053649.540891-1-almasrymina@google.com > > so we could just go with that? I reckon it'd be worth having that as a separate patch atop, to split the infrastructure from the actual change, but I'm happy to go with 16B immediately if you'd prefer. It'd be nice if we could get some numbers... Thanks, Mark.
diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h index 1436fa1cde24d..df18a3446ce82 100644 --- a/arch/arm64/include/asm/linkage.h +++ b/arch/arm64/include/asm/linkage.h @@ -5,8 +5,14 @@ #include <asm/assembler.h> #endif -#define __ALIGN .align 2 -#define __ALIGN_STR ".align 2" +#if CONFIG_FUNCTION_ALIGNMENT > 0 +#define ARM64_FUNCTION_ALIGNMENT CONFIG_FUNCTION_ALIGNMENT +#else +#define ARM64_FUNCTION_ALIGNMENT 4 +#endif + +#define __ALIGN .balign ARM64_FUNCTION_ALIGNMENT +#define __ALIGN_STR ".balign " #ARM64_FUNCTION_ALIGNMENT /* * When using in-kernel BTI we need to ensure that PCS-conformant