All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <jszhang@kernel.org>
To: Andy Chiu <tchiu@tenstorrent.com>
Cc: Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Samuel Holland <samuel.holland@sifive.com>,
	linux-riscv@lists.infradead.org, andybnac@gmail.com,
	dfustini@oss.tenstorrent.com, greentime.hu@sifive.com
Subject: Re: [PATCH v1] riscv: kconfig: enable -mtune built kernel
Date: Wed, 11 Nov 2026 23:13:54 +0800	[thread overview]
Message-ID: <avSGMnFGCw-oKdsP@xhacker> (raw)
In-Reply-To: <20261110200800.1073859-1-tchiu@tenstorrent.com>

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.
> 
> 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.

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.

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

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

      reply	other threads:[~2026-11-11 15:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 20:07 [PATCH v1] riscv: kconfig: enable -mtune built kernel Andy Chiu
2026-11-11 15:13 ` Jisheng Zhang [this message]

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=avSGMnFGCw-oKdsP@xhacker \
    --to=jszhang@kernel.org \
    --cc=alex@ghiti.fr \
    --cc=andybnac@gmail.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=dfustini@oss.tenstorrent.com \
    --cc=greentime.hu@sifive.com \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=samuel.holland@sifive.com \
    --cc=tchiu@tenstorrent.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.