Re: [PATCH 7/9] riscv: Prepare for unaligned access type table lookups

[Andrew Jones <ajones@ventanamicro.com>]

On Mon, Feb 10, 2025 at 09:37:10PM +0100, Clément Léger wrote:
> 
> 
> On 10/02/2025 18:19, Charlie Jenkins wrote:
> > On Mon, Feb 10, 2025 at 03:46:46PM +0530, Anup Patel wrote:
> >> On Sat, Feb 8, 2025 at 6:53 AM Charlie Jenkins <charlie@rivosinc.com> wrote:
> >>>
> >>> On Fri, Feb 07, 2025 at 05:19:47PM +0100, Andrew Jones wrote:
> >>>> Probing unaligned accesses on boot is time consuming. Provide a
> >>>> function which will be used to look up the access type in a table
> >>>> by id registers. Vendors which provide table entries can then skip
> >>>> the probing.
> >>>
> >>> The access checker in my experience is only time consuming on slow
> >>> hardware. Hardware that supports fast unaligned accesses isn't really
> >>> impacted by this? Avoiding a list of hardware that has slow/fast
> >>> unaligned accesses in the kernel was the main reason for dynamically
> >>> checking. We did introduce the config option to compile the kernel with
> >>> assumed slow/fast accesses, which of course has the downside of
> >>> recompiling the kernel and I assume that you already considered that.
> >>
> >> The kconfig option does not align with the vision of running the same
> >> kernel image across platforms.
> > 
> > I just don't think that vision is realistic.
> > 
> > I am a proponent for compile time defines because ri ght now we are
> > catering the kernel to both microcontrollers and for high performance
> > platforms. I am in favor of having a set of configur ations that are
> > ideal for these microcontrollers and a different set for high
> > performance platforms. This is where the RVI profile s would ideally
> > come in, having different configs for different profiles that target low
> > performance/high performance.
> > 
> > Compiler optimizations for extensions are not possib le to do by just
> > having these different methods of selecting at runti me. By enabling
> > extra extensions like the bitmanip extensions during compilation via a
> > config flag we can optimize the entire kernel. It is not possible to
> > push all optimizations off to runtime detection.
> 
> While this might be true for the bitmanip extension and other extensions
> that the compiler can take advantage of, that isn't true for the
> misaligned speed probing code. The only meaningful misaligned access
> configuration option for kernel "speed" optimization is
> RISCV_EFFICIENT_UNALIGNED_ACCESS (which is ironically not easily
> selectable since it is under NON_PORTABLE).
> 
> Currently all the config options that have been added around misaligned
> support "just" allows to get rid of the probing code at compile time and
> set a predefined speed. That does not really improve the kernel
> performance itself, just allows for a faster boot. That could as well be
> supported using a command line option as suggested.

I agree. I'll look into stripping config options and picking up Jesse's
command line option for v2. I'll also drop the table approach of this
series since I don't have a strong enough justification for it over the
command line at this time.

Thanks,
drew

> 
> That being said, I agree that some additional configuration options
> should be added to enable additional extension support at compile time,
> enabling a faster kernel. Having a single image for all hardware is as
> you said not realistic but profiles configuration as you proposed might
> be the key for this support.
> 
> Clément
> 
> > 
> >>
> >>>
> >>> Instead of having a table in the kernel, something that would be more
> >>> platform agnostic would be to have an extension that signals this
> >>> information. That seems like it would accomplish the same goal and
> >>> leverage the existing infrastructure in the kernel, albeit with the need
> >>> to make a new extension.
> >>>
> >>
> >> IMO, expecting an ISA extension to be defined for all possible
> >> microarchitectural choices is not going to scale so it is better
> >> to have infrastructure in kernel itself to infer microarchitectural
> >> choices based on RISC-V implementation ID.
> > 
> > How is keeping tables in the kernel for all microarchitectural details
> > any more scalable than having extensions that do the same thing? I would
> > argue that having it in the kernel is less scalable since it needs to be
> > described for all implementation IDs, and all changes require going
> > through the kernel review process. Dynamic probing avoids these issues.
> > Having an extension has the one-time process of getting the extension
> > into something like a profile, but then anybody could use it without
> > needing a kernel patch.
> > 
> > - Charlie
> > 
> >>
> >> Regards,
> >> Anup
> > 
> > _______________________________________________
> > 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