[PATCH v2 6/6] RISC-V: hwprobe: Document unaligned vector perf key

Jesse Taube posted 6 patches 1 year, 8 months ago
There is a newer version of this series
[PATCH v2 6/6] RISC-V: hwprobe: Document unaligned vector perf key
Posted by Jesse Taube 1 year, 8 months ago
Document key for reporting the speed of unaligned vector accesses.
The descriptions are the same as the scalar equivalent values.

Signed-off-by: Jesse Taube <jesse@rivosinc.com>
---
V1 -> V2:
  - New patch
---
 Documentation/arch/riscv/hwprobe.rst | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
index 7085a694b801..344bea1e21bd 100644
--- a/Documentation/arch/riscv/hwprobe.rst
+++ b/Documentation/arch/riscv/hwprobe.rst
@@ -236,3 +236,19 @@ The following keys are defined:
 
 * :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
   represents the size of the Zicboz block in bytes.
+
+* :c:macro:`RISCV_HWPROBE_KEY_VEC_MISALIGNED_PERF`: An enum value describing the
+  performance of misaligned vector accesses on the selected set of processors.
+
+  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_UNKNOWN`: The performance of misaligned
+    accesses is unknown.
+
+  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_SLOW`: Misaligned 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_VEC_MISALIGNED_FAST`: Misaligned accesses are faster
+    than equivalent byte accesses.
+
+  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
+    not supported at all and will generate a misaligned address fault.
-- 
2.43.0
Re: [PATCH v2 6/6] RISC-V: hwprobe: Document unaligned vector perf key
Posted by Evan Green 1 year, 7 months ago
On Thu, Jun 13, 2024 at 12:18 PM Jesse Taube <jesse@rivosinc.com> wrote:
>
> Document key for reporting the speed of unaligned vector accesses.
> The descriptions are the same as the scalar equivalent values.
>
> Signed-off-by: Jesse Taube <jesse@rivosinc.com>
> ---
> V1 -> V2:
>   - New patch
> ---
>  Documentation/arch/riscv/hwprobe.rst | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index 7085a694b801..344bea1e21bd 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -236,3 +236,19 @@ The following keys are defined:
>
>  * :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
>    represents the size of the Zicboz block in bytes.
> +
> +* :c:macro:`RISCV_HWPROBE_KEY_VEC_MISALIGNED_PERF`: An enum value describing the
> +  performance of misaligned vector accesses on the selected set of processors.
> +
> +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_UNKNOWN`: The performance of misaligned
> +    accesses is unknown.
> +
> +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_SLOW`: Misaligned accesses are slower

Should we specify what size of vector access we're comparing against?
In other words, crispen up what "misaligned access" exactly means. I
realize you copied this from my text. I really should have said
"misaligned native word size accesses".

> +    than equivalent byte accesses.  Misaligned accesses may be supported
> +    directly in hardware, or trapped and emulated by software.
> +
> +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_FAST`: Misaligned accesses are faster
> +    than equivalent byte accesses.
> +
> +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
> +    not supported at all and will generate a misaligned address fault.
> --
> 2.43.0
>
Re: [PATCH v2 6/6] RISC-V: hwprobe: Document unaligned vector perf key
Posted by Jesse Taube 1 year, 7 months ago
On Thu, Jun 20, 2024 at 2:52 PM Evan Green <evan@rivosinc.com> wrote:
>
> On Thu, Jun 13, 2024 at 12:18 PM Jesse Taube <jesse@rivosinc.com> wrote:
> >
> > Document key for reporting the speed of unaligned vector accesses.
> > The descriptions are the same as the scalar equivalent values.
> >
> > Signed-off-by: Jesse Taube <jesse@rivosinc.com>
> > ---
> > V1 -> V2:
> >   - New patch
> > ---
> >  Documentation/arch/riscv/hwprobe.rst | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> > index 7085a694b801..344bea1e21bd 100644
> > --- a/Documentation/arch/riscv/hwprobe.rst
> > +++ b/Documentation/arch/riscv/hwprobe.rst
> > @@ -236,3 +236,19 @@ The following keys are defined:
> >
> >  * :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
> >    represents the size of the Zicboz block in bytes.
> > +
> > +* :c:macro:`RISCV_HWPROBE_KEY_VEC_MISALIGNED_PERF`: An enum value describing the
> > +  performance of misaligned vector accesses on the selected set of processors.
> > +
> > +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_UNKNOWN`: The performance of misaligned
> > +    accesses is unknown.
> > +
> > +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_SLOW`: Misaligned accesses are slower
>
> Should we specify what size of vector access we're comparing against?
> In other words, crispen up what "misaligned access" exactly means. I
> realize you copied this from my text. I really should have said
> "misaligned native word size accesses".

In arch/riscv/kernel/vec-copy-unaligned.S I set WORD_EEW to 32bits.
The rationale for using 32bits is
("riscv: vector: adjust minimum Vector requirement to ZVE32X") in this set.
https://lore.kernel.org/all/20240412-zve-detection-v4-0-e0c45bb6b253@sifive.com/

I'll change faste and slow to start with "32bit misaligned accesses are"

Thanks,
Jesse
>
> > +    than equivalent byte accesses.  Misaligned accesses may be supported
> > +    directly in hardware, or trapped and emulated by software.
> > +
> > +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_FAST`: Misaligned accesses are faster
> > +    than equivalent byte accesses.
> > +
> > +  * :c:macro:`RISCV_HWPROBE_VEC_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
> > +    not supported at all and will generate a misaligned address fault.
> > --
> > 2.43.0
> >