Message-ID: <65f48829-56d2-47fc-8f61-074ff122d964@rivosinc.com>
Date: Mon, 10 Feb 2025 21:37:10 +0100
From: Clément Léger <cleger@...osinc.com>
To: Charlie Jenkins <charlie@...osinc.com>, Anup Patel <anup@...infault.org>
Cc: Andrew Jones <ajones@...tanamicro.com>, linux-riscv@...ts.infradead.org,
 linux-kernel@...r.kernel.org, paul.walmsley@...ive.com, palmer@...belt.com,
 jesse@...osinc.com, Anup Patel <apatel@...tanamicro.com>
Subject: Re: [PATCH 7/9] riscv: Prepare for unaligned access type table
 lookups



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

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@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists