On Tue, Jun 25, 2024 at 12:08:09PM -0700, Evan Green wrote:
> On Tue, Jun 25, 2024 at 11:35 AM Conor Dooley <conor@xxxxxxxxxx> wrote:
> >
> > On Tue, Jun 25, 2024 at 09:51:21AM -0700, Evan Green wrote:
> > > In preparation for misaligned vector performance hwprobe keys, rename
> > > the hwprobe key values associated with misaligned scalar accesses to
> > > include the term SCALAR.
> > >
> > > Signed-off-by: Evan Green <evan@xxxxxxxxxxxx>
> > >
> > > ---
> > >
> > > Changes in v2:
> > > - Added patch to rename misaligned perf key values (Palmer)
> > >
> > > Documentation/arch/riscv/hwprobe.rst | 20 ++++++++++----------
> > > arch/riscv/include/uapi/asm/hwprobe.h | 10 +++++-----
> > > arch/riscv/kernel/sys_hwprobe.c | 10 +++++-----
> > > arch/riscv/kernel/traps_misaligned.c | 6 +++---
> > > arch/riscv/kernel/unaligned_access_speed.c | 12 ++++++------
> > > 5 files changed, 29 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> > > index c9f570b1ab60..83f7f3c1347f 100644
> > > --- a/Documentation/arch/riscv/hwprobe.rst
> > > +++ b/Documentation/arch/riscv/hwprobe.rst
> > > @@ -215,22 +215,22 @@ The following keys are defined:
> > > the performance of misaligned scalar word accesses on the selected set of
> > > processors.
> > >
> > > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNKNOWN`: The performance of misaligned
> > > - accesses is unknown.
> > > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN`: The performance of
> > > + misaligned accesses is unknown.
> > >
> > > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_EMULATED`: Misaligned accesses are
> > > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED`: Misaligned accesses are
> > > emulated via software, either in or below the kernel. These accesses are
> > > always extremely slow.
> > >
> > > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned word accesses are
> > > - slower than equivalent byte accesses. Misaligned accesses may be supported
> > > - directly in hardware, or trapped and emulated by software.
> > > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW`: Misaligned word accesses
> > > + are slower than equivalent byte accesses. Misaligned accesses may be
> > > + supported directly in hardware, or trapped and emulated by software.
> > >
> > > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned word accesses are
> > > - faster than equivalent byte accesses.
> > > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_FAST`: Misaligned word accesses
> > > + are faster than equivalent byte accesses.
> > >
> > > - * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
> > > - not supported at all and will generate a misaligned address fault.
> > > + * :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED`: Misaligned accesses
> > > + are not supported at all and will generate a misaligned address fault.
> > >
> > > * :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
> > > represents the size of the Zicboz block in bytes.
> > > diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> > > index 22073533cea8..e11684d8ae1c 100644
> > > --- a/arch/riscv/include/uapi/asm/hwprobe.h
> > > +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> > > @@ -66,11 +66,11 @@ struct riscv_hwprobe {
> > > #define RISCV_HWPROBE_EXT_ZVE64F (1ULL << 40)
> > > #define RISCV_HWPROBE_EXT_ZVE64D (1ULL << 41)
> > > #define RISCV_HWPROBE_KEY_CPUPERF_0 5
> > > -#define RISCV_HWPROBE_MISALIGNED_UNKNOWN 0
> > > -#define RISCV_HWPROBE_MISALIGNED_EMULATED 1
> > > -#define RISCV_HWPROBE_MISALIGNED_SLOW 2
> > > -#define RISCV_HWPROBE_MISALIGNED_FAST 3
> > > -#define RISCV_HWPROBE_MISALIGNED_UNSUPPORTED 4
> > > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_UNKNOWN 0
> > > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_EMULATED 1
> > > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW 2
> > > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_FAST 3
> > > +#define RISCV_HWPROBE_MISALIGNED_SCALAR_UNSUPPORTED 4
> > > #define RISCV_HWPROBE_MISALIGNED_MASK 7
> >
> > How come the "old" names do not need to be preserved for userspace?
>
> It depends on what exactly the big userspace compatibility rule is.
> This preserves binary compatibility, which I think is the big one, but
> breaks source compatibility, though with an easy translation to fix.
> We could keep the old names around, but then it seems sort of silly to
> introduce the new names. I introduced this patch upon request, so I
> don't personally have a horse in the race on this one.
So apparently this isn't quite Palmer actually wanted. In today's call
he suggested that he'd send a new version himself, but also that what we
should do define a new key for scalar /and/ new add new defines values that
contain the word scalar, retaining the old defines. The values can of
course be the same.
Attachment:
signature.asc
Description: PGP signature
