Evan Green 584ea6564b RISC-V: Probe for unaligned access speed ... Rather than deferring unaligned access speed determinations to a vendor function, let's probe them and find out how fast they are. If we determine that an unaligned word access is faster than N byte accesses, mark the hardware's unaligned access as "fast". Otherwise, we mark accesses as slow. The algorithm itself runs for a fixed amount of jiffies. Within each iteration it attempts to time a single loop, and then keeps only the best (fastest) loop it saw. This algorithm was found to have lower variance from run to run than my first attempt, which counted the total number of iterations that could be done in that fixed amount of jiffies. By taking only the best iteration in the loop, assuming at least one loop wasn't perturbed by an interrupt, we eliminate the effects of interrupts and other "warm up" factors like branch prediction. The only downside is it depends on having an rdtime granular and accurate enough to measure a single copy. If we ever manage to complete a loop in 0 rdtime ticks, we leave the unaligned setting at UNKNOWN. There is a slight change in user-visible behavior here. Previously, all boards except the THead C906 reported misaligned access speed of UNKNOWN. C906 reported FAST. With this change, since we're now measuring misaligned access speed on each hart, all RISC-V systems will have this key set as either FAST or SLOW. Currently, we don't have a way to confidently measure the difference between SLOW and EMULATED, so we label anything not fast as SLOW. This will mislabel some systems that are actually EMULATED as SLOW. When we get support for delegating misaligned access traps to the kernel (as opposed to the firmware quietly handling it), we can explicitly test in Linux to see if unaligned accesses trap. Those systems will start to report EMULATED, though older (today's) systems without that new SBI mechanism will continue to report SLOW. I've updated the documentation for those hwprobe values to reflect this, specifically: SLOW may or may not be emulated by software, and FAST represents means being faster than equivalent byte accesses. The change in documentation is accurate with respect to both the former and current behavior. Signed-off-by: Evan Green <evan@rivosinc.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230818194136.4084400-2-evan@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>		2023-09-01 09:06:25 -07:00
..
boot	RISC-V Devicetrees for v6.5 Part 2	2023-06-20 23:06:54 +02:00
configs	RISC-V Patches for the 6.5 Merge Window, Part 1	2023-06-30 09:37:26 -07:00
errata	Merge patch series "riscv: some CMO alternative related clean up"	2023-07-06 10:32:38 -07:00
include	RISC-V: Probe for unaligned access speed	2023-09-01 09:06:25 -07:00
kernel	RISC-V: Probe for unaligned access speed	2023-09-01 09:06:25 -07:00
kvm	ARM64:	2023-07-03 15:32:22 -07:00
lib	riscv: Allow to downgrade paging mode from the command line	2023-04-26 07:30:52 -07:00
mm	RISC-V Patches for the 6.5 Merge Window, Part 2	2023-07-07 10:07:19 -07:00
net	Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net	2023-03-09 22:22:11 -08:00
purgatory	hardening updates for v6.5-rc1	2023-06-27 21:24:18 -07:00
tools	riscv: Check relocations at compile time	2023-04-19 07:46:32 -07:00
Kbuild	riscv: move errata/ and kvm/ builds to arch/riscv/Kbuild	2022-06-01 22:26:32 -07:00
Kconfig	RISC-V Patches for the 6.5 Merge Window, Part 2	2023-07-07 10:07:19 -07:00
Kconfig.debug
Kconfig.errata	Merge patch series "RISC-V: Fixes for riscv_has_extension[un]likely()'s alternative dependency"	2023-03-29 12:26:38 -07:00
Kconfig.socs	RISC-V: make ARCH_THEAD preclude XIP_KERNEL	2023-07-05 22:21:23 +02:00
Makefile	riscv: Enable Vector code to be built	2023-06-08 07:16:56 -07:00
Makefile.postlink	riscv: Use --emit-relocs in order to move .rela.dyn in init	2023-04-19 07:46:33 -07:00