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

[Charlie Jenkins <charlie@rivosinc.com>]

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.

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