Re: [PATCH 2/3] RISC-V: Detect unaligned vector accesses supported.

From: Charlie Jenkins <charlie@rivosinc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Jesse Taube" <jesse@rivosinc.com>,
	linux-riscv@lists.infradead.org,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Albert Ou" <aou@eecs.berkeley.edu>,
	"Conor Dooley" <conor.dooley@microchip.com>,
	"Evan Green" <evan@rivosinc.com>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Xiao Wang" <xiao.w.wang@intel.com>,
	"Clément Léger" <cleger@rivosinc.com>,
	"Andy Chiu" <andy.chiu@sifive.com>,
	"Greentime Hu" <greentime.hu@sifive.com>,
	"Heiko Stuebner" <heiko@sntech.de>, "Guo Ren" <guoren@kernel.org>,
	"Björn Töpel" <bjorn@rivosinc.com>,
	"Costa Shulyupin" <costa.shul@redhat.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Baoquan He" <bhe@redhat.com>,
	"Sami Tolvanen" <samitolvanen@google.com>,
	"Zong Li" <zong.li@sifive.com>,
	"Ben Dooks" <ben.dooks@codethink.co.uk>,
	"Erick Archer" <erick.archer@gmx.com>,
	"Vincent Chen" <vincent.chen@sifive.com>,
	"Joel Granados" <j.granados@samsung.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] RISC-V: Detect unaligned vector accesses supported.
Date: Fri, 7 Jun 2024 14:32:48 -0700	[thread overview]
Message-ID: <ZmN8gER4RnyoyQT4@ghost> (raw)
In-Reply-To: <20240607-wildfowl-baggage-54f622e18c4a@spud>

On Fri, Jun 07, 2024 at 10:21:19PM +0100, Conor Dooley wrote:
> On Fri, Jun 07, 2024 at 02:06:27PM -0700, Charlie Jenkins wrote:
> > On Fri, Jun 07, 2024 at 03:53:23PM -0400, Jesse Taube wrote:
> > > On 6/6/24 19:13, Charlie Jenkins wrote:
> > > > On Thu, Jun 06, 2024 at 02:29:23PM -0700, Charlie Jenkins wrote:
> > > > > On Thu, Jun 06, 2024 at 02:32:14PM -0400, Jesse Taube wrote:
> 
> > > > > Please use the exising UNKNOWN terminology instead of renaming to
> > > > > SUPPORTED. Any option that is not UNSUPPORTED implies that unaligned
> > > > > accesses are supported.
> > > 
> > > Conor didnt like using UNKNOWN a proxy for "SUPPORTED"
> 
> I did say this, but in the context of wanting you to actually add the
> performance probing (and potentially the other infrastructure that
> Charlie added for scalar).
> 
> > > Having SUPPORTED is better then assuing the speed to be slow.
> > 
> > The HWPROBE key is about misaligned access performance. UNKNOWN means
> > that the performance is unknown.
> 
> Right. I also don't think that assuming "slow" is even problematic -
> seemingly all extant hardware doesn't even support misaligned access.
> But really, just whack in the probing, it shouldn't be too bad, right?
>

Yeah that's a good point, slow is a reasonable default.

> > The scalar and vector names need to
> > match up.
> 
> That's definitely not the case. A different hwprobe key is allowed to
> behave differently, but...

It of course can behave differently in purely technical sense, I said
"need" because it would not be a very intuitive interface to have a
different name for vector and scalar versions of the same thing.

> 
> > UNKNOWN was already merged and is supported by linux so if you
> > want to use SUPPORTED here then you need to add a scalar SUPPORTED key
> > that is an alias of the UNKNOWN key.
> 
> ...this suggestion of a scalar change I disagree with anyway, so it's
> moot. Unknown should be a state that we only have internally when we
> actually do not know, and not something that userspace should ever see,
> unless there's a bug in the probing code IMO. Unknown gives userspace no
> actionable information anyways.
> 

I agree, returning slow is probably always be more useful than unknown.

- Charlie

> > I would rather keep UNKNOWN as it
> > is, but that's up to you.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv