Re: riscv: kconfig: enable -mtune built kernel

[Jisheng Zhang <jszhang@kernel.org>]

On Fri, Nov 13, 2026 at 10:58:15AM -0600, Andy Chiu wrote:
> On Wed, Nov 11, 2026 at 11:13:54PM +0800, Jisheng Zhang wrote:
> > On Tue, Nov 10, 2026 at 02:07:59PM -0600, Andy Chiu wrote:
> > > On a machine that supports native unaligned access, enabling unaligned
> > > access code-gen can result in a significant speedup on certain workloads.
> > > As the adoption of application-level core increases, it has become
> > > essential to build a kernel utilizing what's available on the platform.
> > > 
> > > Here are the examples of throughput improvement when the build is
> > > configured to utilize misaligned access code-gen:
> > > 
> > > LZ4 compress: +90.6% (Ascalon-X), +35.1% (K3-X100)
> > > LZ4 decompress: +9.8% (Ascalon-X), +76.6% (K3-X100)
> > > ZSTD compress: +35.4% (Ascaloon-X), +19.4% (K3-X100)
> > > ZSTD decompress: +26.0% (Ascalon-X), +7.5% (K3-X100)
> > > 
> > > btrfs create: +7.4% (Ascalon-X), +4.5% (K3-X100)
> > > btrfs unlink: +7.2% (Ascalon-X), +2.6% (K3-X100)
> > 
> > how much improvement is from unaliagned access, and how much is from
> > -mtune. So these numbers don't explain why -mtune is neceesary.
> 
> Native unaligned access is enabled only by selecting the -mtune that
> assumes fast misaliged access. E.g. there is no single flag that turns
> on native unaligned access code-gen alone. The detailed options are coded
> in the compiler's souce code under gcc/config/riscv/riscv.cc

by "unaliagned access" I mean enable RISCV_EFFICIENT_UNALIGNED_ACCESS.
So can you plz show performance gain of
RISCV_EFFICIENT_UNALIGNED_ACCESS vs. RISCV_EFFICIENT_UNALIGNED_ACCESS + mtune

> 
> > > 
> > > To enable such code-gen, the build system not only has to remove
> > > -mstrict-align restriction, but also needs to set the proper -mtune cost
> > > model to emit such accesses. -mstrict-align is gated by NONPORTABLE and
> > > RISCV_EFFICIENT_UNALIGNED_ACCESS, and -mtune=generic-ooo enables the
> > 
> > 
> > Following the same reason as arm64, I don't think we should introduce
> > per-cpu -mtune options into arch/riscv/Kconfig.
> 
> Unfortunately we are not like arm64 where it has the ecosyetem authority
> to mandate all platform to support fast misaligned access. Fragmentation
> is destined in riscv and, though not personally convinced, people
> celebrate it.
> 
> > 
> > IIRC, arm64 intentionally avoided adding -mtune options to Kconfig to
> > prevent endless per-vendor or even per-cpu option bloat, toolchain
> > flag churn, and fragmention away from a sigle Image.
> > 
> 
> Software that runs on embedded core can perform poorly on a more
> advanced hardware. That is the nature of how optimization works.
> 
> With the availability of RVA23 hardware and the increasing supports from
> distro vendors, I don't see a reason why we should hold back the
> ecosystem progression under the illusion of harmony.
> 
> > >From another side, when someone needs a custom -mtune for a fixed
> > target, they can pass the already well supported KCFLAGS="-mtune ..."
> > at build time without needing dedicated Kconfig symbols for every
> > core.
> > 
> > Furthermore, having an -mtune option silently select NONPORTABLE and
> > RISCV_EFFICIENT_UNALIGNED_ACCESS breaks user expectations. NONPORTABLE
> > breaks cross platform compatibility, while -mtune is just a compiler
> > scheduling hint
> > 
> 
> Again following the adoption of RVA23 profile, we foresee that it is
> going to have a clear split of the software ecosystem and it is not
> *portable* by design. On the distro end of the world, there is a need
> for native misaligned access support, which turns off -mstrict-align and
> kicks in generic-ooo mtune, whether it is defined in KCFLAGS or set as
> the toolchain default.

There's misunderstanding here. I didn't say "-mtune" doesn't help, my main
point is I didn't see the necessity of dedicated RISCV_MTUNE Kconfig
option given the well supported KCFLAGS +
RISCV_EFFICIENT_UNALIGNED_ACCESS can acchieve the same effect, while
RISCV_MTUNE adds endless per-vendor or even per-cpu option bloat.

> 
> We do not forbid people from building software that runs extremely slow in
> order to support *all* hardware, and we don't see enabling native
> misaligned access would break any hardware that is supposed to run
> distro-level applications.
> 
> Cheers,
> Andy
> 
> > thanks
> > 
> > > code-gen to emit misaligned accesses.
> > > 
> > > Add an entry in Kconfig so it allows the build system to select different
> > > mtune options. Also, select NONPORTABLE and
> > > RISCV_EFFICIENT_UNALIGNED_ACCESS when building with "generic-ooo", and
> > > "tt-ascalon-d8".
> > > 
> > > Signed-off-by: Andy Chiu <tchiu@tenstorrent.com>
> > > ---
> > >  arch/riscv/Kconfig  | 62 +++++++++++++++++++++++++++++++++++++++++++++
> > >  arch/riscv/Makefile | 14 ++++++++++
> > >  2 files changed, 76 insertions(+)
> > >> > > 
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index e7891a2a89da..d53225fead4a 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -980,8 +980,67 @@ config RISCV_SBI_FWFT_DELEGATE_MISALIGNED
> > >  
> > >  	  If you don't know what to do here, say N.
> > >  
> > > +config TOOLCHAIN_HAS_MTUNE_TT_ASCALON_D8
> > > +	def_bool $(cc-option,-mtune=tt-ascalon-d8)
> > > +
> > > +choice
> > > +	prompt "CPU tuning (-mtune)"
> > > +	default RISCV_MTUNE_TOOLCHAIN_DEFAULT
> > > +	help
> > > +	  Select the microarchitecture the compiler should tune the kernel
> > > +	  for. This only affects instruction scheduling and cost models, not
> > > +	  the ISA, but some choices also assume fast unaligned accesses and
> > > +	  therefore result in a non-portable kernel.
> > > +
> > > +config RISCV_MTUNE_TOOLCHAIN_DEFAULT
> > > +	bool "Toolchain default"
> > > +	help
> > > +	  Do not pass -mtune; use whatever the toolchain was configured with.
> > > +
> > > +config RISCV_MTUNE_GENERIC_OOO
> > > +	bool "generic-ooo"
> > > +	depends on $(cc-option,-mtune=generic-ooo)
> > > +	select NONPORTABLE
> > > +	select RISCV_MTUNE_FAST_UNALIGNED
> > > +	help
> > > +	  Tune for a generic out-of-order core (-mtune=generic-ooo). This
> > > +	  also assumes fast unaligned scalar accesses.
> > > +
> > > +config RISCV_MTUNE_TT_ASCALON
> > > +	bool "Tenstorrent Ascalon"
> > > +	depends on TOOLCHAIN_HAS_MTUNE_TT_ASCALON_D8
> > > +	select NONPORTABLE
> > > +	select RISCV_MTUNE_FAST_UNALIGNED
> > > +	help
> > > +	  Tune for the Tenstorrent Ascalon core (-mtune=tt-ascalon-d8). This
> > > +	  also assumes fast unaligned scalar accesses.
> > > +
> > > +config RISCV_MTUNE_CUSTOM
> > > +	bool "Custom"
> > > +	help
> > > +	  Pass -mtune=<RISCV_MTUNE> to the compiler.
> > > +
> > > +endchoice
> > > +
> > > +config RISCV_MTUNE
> > > +	string "Custom -mtune value" if RISCV_MTUNE_CUSTOM
> > > +	default "generic-ooo" if RISCV_MTUNE_GENERIC_OOO
> > > +	default "tt-ascalon-d8" if RISCV_MTUNE_TT_ASCALON
> > > +	default ""
> > > +	help
> > > +	  The value passed to -mtune=, e.g. "sifive-7-series". Only
> > > +	  editable when the "Custom" CPU tuning is selected, in which case
> > > +	  it must not be empty or the build will fail.
> > > +
> > > +config RISCV_MTUNE_FAST_UNALIGNED
> > > +	bool
> > > +	help
> > > +	  Selected by -mtune choices that imply fast unaligned scalar
> > > +	  accesses. Forces RISCV_EFFICIENT_UNALIGNED_ACCESS.
> > > +
> > >  choice
> > >  	prompt "Unaligned Accesses Support"
> > > +	default RISCV_EFFICIENT_UNALIGNED_ACCESS if RISCV_MTUNE_FAST_UNALIGNED
> > >  	default RISCV_PROBE_UNALIGNED_ACCESS
> > >  	help
> > >  	  This determines the level of support for unaligned accesses. This
> > > @@ -991,6 +1050,7 @@ choice
> > >  
> > >  config RISCV_PROBE_UNALIGNED_ACCESS
> > >  	bool "Probe for hardware unaligned access support"
> > > +	depends on !RISCV_MTUNE_FAST_UNALIGNED
> > >  	select RISCV_SCALAR_MISALIGNED
> > >  	help
> > >  	  During boot, the kernel will run a series of tests to determine the
> > > @@ -1002,6 +1062,7 @@ config RISCV_PROBE_UNALIGNED_ACCESS
> > >  
> > >  config RISCV_EMULATED_UNALIGNED_ACCESS
> > >  	bool "Emulate unaligned access where system support is missing"
> > > +	depends on !RISCV_MTUNE_FAST_UNALIGNED
> > >  	select RISCV_SCALAR_MISALIGNED
> > >  	help
> > >  	  If unaligned memory accesses trap into the kernel as they are not
> > > @@ -1012,6 +1073,7 @@ config RISCV_EMULATED_UNALIGNED_ACCESS
> > >  config RISCV_SLOW_UNALIGNED_ACCESS
> > >  	bool "Assume the system supports slow unaligned memory accesses"
> > >  	depends on NONPORTABLE
> > > +	depends on !RISCV_MTUNE_FAST_UNALIGNED
> > >  	help
> > >  	  Assume that the system supports slow unaligned memory accesses. The
> > >  	  kernel and userspace programs may not be able to run at all on systems
> > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > > index 44f5a439741a..08f1a32228ef 100644
> > > --- a/arch/riscv/Makefile
> > > +++ b/arch/riscv/Makefile
> > > @@ -89,6 +89,11 @@ CC_FLAGS_FPU  := -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64i
> > >  
> > >  KBUILD_CFLAGS += -mno-save-restore
> > >  
> > > +riscv-mtune := $(CONFIG_RISCV_MTUNE:"%"=%)
> > > +ifneq ($(riscv-mtune),)
> > > +KBUILD_CFLAGS += -mtune=$(riscv-mtune)
> > > +endif
> > > +
> > >  ifeq ($(CONFIG_CMODEL_MEDLOW),y)
> > >  	KBUILD_CFLAGS += -mcmodel=medlow
> > >  endif
> > > @@ -149,6 +154,15 @@ KBUILD_IMAGE				:= $(boot)/$(boot-image-y)
> > >  libs-y += arch/riscv/lib/
> > >  libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> > >  
> > > +archprepare: checkmtune
> > > +PHONY += checkmtune
> > > +checkmtune:
> > > +ifeq ($(CONFIG_RISCV_MTUNE_CUSTOM)$(riscv-mtune),y)
> > > +	@echo '*** CONFIG_RISCV_MTUNE_CUSTOM is set but CONFIG_RISCV_MTUNE is empty.' >&2
> > > +	@echo '*** Set the custom -mtune value or pick another CPU tuning.' >&2
> > > +	@false
> > > +endif
> > > +
> > >  ifeq ($(KBUILD_EXTMOD),)
> > >  ifeq ($(CONFIG_MMU),y)
> > >  prepare: vdso_prepare
> > > -- 
> > > 2.43.0
> > > 
> > > 
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv