On Mon, Aug 5, 2024 at 11:48 AM Charlie Jenkins <charlie@xxxxxxxxxxxx> wrote: > > On Mon, Aug 05, 2024 at 11:38:23AM -0700, Evan Green wrote: > > On Mon, Aug 5, 2024 at 10:38 AM Jesse Taube <jesse@xxxxxxxxxxxx> wrote: > > > > > > Add a kernel parameter to the unaligned access speed. This allows > > > skiping of the speed tests for unaligned accesses, which often is very > > > slow. > > > > > > Signed-off-by: Jesse Taube <jesse@xxxxxxxxxxxx> > > > > How come this is a command line parameter rather than a Kconfig > > option? I could be wrong, so I'll lay out my rationale and people can > > pick it apart if I've got a bad assumption. > > > > I think of commandline parameters as (mostly) something end users > > twiddle with, versus kconfig options as something system builders set > > up. I'd largely expect end users not to notice two ticks at boot time. > > I'd expect its system builders and fleet managers, who know their > > hardware and build their kernels optimized for it, are the ones who > > would want to shave off this time and go straight to the known answer. > > Anecdotally, at ChromeOS we had a strong preference for Kconfig > > options, as they were easier to compose and maintain than a loose pile > > of commandline arguments. > > > > The commit text doesn't go into the rationale, intended audience, or > > expected usage, so maybe my guesses miss the mark on what you're > > thinking. > > -Evan > > There was a brief discussion about this on Jesse's series about vector > unaligned support [1]. The original idea was to use Zicclsm to allow > people to set the unaligned access speed on pre-compiled distro kernels. > However Zicclsm isn't useful so the alternative route was to use a > kernel arg. There is already support for a Kconfig, the kernel arg is > just another option for users. > > Link: > https://lore.kernel.org/lkml/af3152b6-adf7-40fa-b2a1-87e66eec45b0@xxxxxxxxxxxx/ > [1] Ah got it, thanks for the explanation Charlie! If there are consumers for this then the concept seems fine with me. -Evan
