From: Mark Rutland <mark.rutland@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
lenb@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, mhiramat@kernel.org,
ndesaulniers@google.com, ojeda@kernel.org,
rafael.j.wysocki@intel.com, revest@chromium.org,
robert.moore@intel.com, rostedt@goodmis.org
Subject: Re: [PATCH 3/8] arm64: Extend support for CONFIG_FUNCTION_ALIGNMENT
Date: Wed, 11 Jan 2023 11:39:02 +0000 [thread overview]
Message-ID: <Y76fxxGPWB2MW5NH@FVFF77S0Q05N> (raw)
In-Reply-To: <20230110204320.GA9739@willie-the-truck>
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.
next prev parent reply other threads:[~2023-01-11 11:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 13:58 [PATCH 0/8] arm64/ftrace: Add support for DYNAMIC_FTRACE_WITH_CALL_OPS Mark Rutland
2023-01-09 13:58 ` [PATCH 1/8] Compiler attributes: GCC function alignment workarounds Mark Rutland
2023-01-09 14:43 ` Miguel Ojeda
2023-01-09 17:06 ` Mark Rutland
2023-01-09 22:35 ` Miguel Ojeda
2023-01-11 18:27 ` Mark Rutland
2023-01-12 11:38 ` Mark Rutland
2023-01-13 12:49 ` Mark Rutland
2023-01-15 21:32 ` Miguel Ojeda
2023-01-09 13:58 ` [PATCH 2/8] ACPI: Don't build ACPICA with '-Os' Mark Rutland
2023-01-10 13:45 ` Rafael J. Wysocki
2023-01-09 13:58 ` [PATCH 3/8] arm64: Extend support for CONFIG_FUNCTION_ALIGNMENT Mark Rutland
2023-01-10 20:35 ` Peter Zijlstra
2023-01-10 20:43 ` Will Deacon
2023-01-11 11:39 ` Mark Rutland [this message]
2023-01-11 11:36 ` Mark Rutland
2023-01-09 13:58 ` [PATCH 4/8] ftrace: Add DYNAMIC_FTRACE_WITH_CALL_OPS Mark Rutland
2023-01-12 6:48 ` Li Huafei
2023-01-12 11:00 ` Mark Rutland
2023-01-13 1:15 ` Li Huafei
2023-01-09 13:58 ` [PATCH 5/8] arm64: insn: Add helpers for BTI Mark Rutland
2023-01-09 13:58 ` [PATCH 6/8] arm64: patching: Add aarch64_insn_write_literal_u64() Mark Rutland
2023-01-09 13:58 ` [PATCH 7/8] arm64: ftrace: Update stale comment Mark Rutland
2023-01-09 13:58 ` [PATCH 8/8] arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS Mark Rutland
2023-01-10 8:55 ` [PATCH 0/8] arm64/ftrace: Add support for DYNAMIC_FTRACE_WITH_CALL_OPS David Laight
2023-01-10 10:31 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y76fxxGPWB2MW5NH@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=catalin.marinas@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=revest@chromium.org \
--cc=robert.moore@intel.com \
--cc=rostedt@goodmis.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox