[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALs-HstYwwgPAOP22V1A6iTX85eRqRp4b4039pewsDHus_dLgQ@mail.gmail.com>
Date: Mon, 5 Aug 2024 11:38:23 -0700
From: Evan Green <evan@...osinc.com>
To: Jesse Taube <jesse@...osinc.com>
Cc: linux-riscv@...ts.infradead.org, Jonathan Corbet <corbet@....net>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Clément Léger <cleger@...osinc.com>,
Andrew Jones <ajones@...tanamicro.com>, Charlie Jenkins <charlie@...osinc.com>,
Xiao Wang <xiao.w.wang@...el.com>, Andy Chiu <andy.chiu@...ive.com>,
Eric Biggers <ebiggers@...gle.com>, Greentime Hu <greentime.hu@...ive.com>,
Björn Töpel <bjorn@...osinc.com>,
Heiko Stuebner <heiko@...ech.de>, Costa Shulyupin <costa.shul@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>,
Anup Patel <apatel@...tanamicro.com>, Zong Li <zong.li@...ive.com>,
Sami Tolvanen <samitolvanen@...gle.com>, Ben Dooks <ben.dooks@...ethink.co.uk>,
Alexandre Ghiti <alexghiti@...osinc.com>, "Gustavo A. R. Silva" <gustavoars@...nel.org>,
Erick Archer <erick.archer@....com>, Joel Granados <j.granados@...sung.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/1] RISC-V: Add parameter to unaligned access speed
On Mon, Aug 5, 2024 at 10:38 AM Jesse Taube <jesse@...osinc.com> 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@...osinc.com>
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
Powered by blists - more mailing lists