[PATCH v3] RISC-V: add multiarch RVV support for memcpy using FMV IFUNC

[daichengrong]

在 2025/1/22 21:24:52, Adhemerval Zanella Netto 写道:
>
> On 22/01/25 09:53, Adhemerval Zanella Netto wrote:
>>
>> On 21/01/25 06:45, daichengrong wrote:
>>> 在 2025/1/20 20:55:09, Adhemerval Zanella Netto 写道:
>>>> On 20/01/25 00:26, daichengrong@iscas.ac.cn wrote:
>>>>> From: daichengrong <daichengrong@iscas.ac.cn>
>>>>>
>>>>> This patch introduces vector support for memcpy with IFUNC.
>>>>> The implementation select the RVV optimized memcpy version via hwprobe on kernel with RVV enabled.
>>>>>
>>>>> Changes in v3:
>>>>>    Remove unnecessary whitespace
>>>>>    
>>>>> Changes in v2:
>>>>>    delete size-0 branch
>>>>>
>>>>> Signed-off-by: daichengrong <daichengrong@iscas.ac.cn>
>>>> For performance improvements the usual way is to also provide some benchmark
>>>> numbers on real hardware (either using our synthetic benchtests or some other
>>>> benchmark that stresses the affected routines).
>>> Thanks! It runs bench-memcpy at K230.
>>>> Also, I take that RISCV_HWPROBE_IMA_V implies in RISCV_HWPROBE_MISALIGNED_FAST
>>>> right?
>>> SPEC says :"Support for misaligned vector memory accesses is independent of an implementation’s support for misaligned scalar memory accesses. "
>> This kernel patchset [1] hints that RVV implementation suffers the same issue of
>> scalar wrt memory access. The RISCV_HWPROBE_MISALIGNED_VECTOR_SLOW is troublesome
>> because it means that misaligned access might be trapped by the kernel (which
>> might render the implementation really slow); but RISCV_HWPROBE_MISALIGNED_VECTOR_UNSUPPORTED
>> is worrisome because it means this implementation will be just wrong in this
>> kind of hardware.
>>
>> So maybe it would be better to either adapt the implementation to only use aligned
>> memory access (with head and tail handling); or wait this kernel patchset to land
>> and enable it only for RISCV_HWPROBE_MISALIGNED_VECTOR_FAST.

For the current implementation of vector memcpy, the operation is 
performed in byte mode.

>> And I am pressing on performance numbers on real hardware because on different
>> hardware there is usually some conditions on when vector instruction do show
>> better performance on string routines (either alignment or size).  Even for
>> x86_64 ERMS on very recent chips requires tuning to avoid performance pitfalls
>> [2] [3].  Maybe RVV requires that this kind of memory access act like AArch64
> This is confunsing, I meant 'Maybe RVV implementations do not require such tuning
> and work like AArch64 MOPS, ...'.
>
>> MOPS, where it is up to hardware to figure out; although the kernel patchset
>> hinted me that it might not be the case for all implementations.
>>
>> Keep in mind that you are proposing a generic implementation, meaning once
>> enabled it would be used for all RISCV chips and not only for K230.  It means
>> that we need to be careful to proper enable and make it future proof.
>>
>> [1] https://patchwork.kernel.org/project/linux-riscv/cover/20241017-jesse_unaligned_vector-v10-0-5b33500160f8@rivosinc.com/
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=30994
>> [3] https://sourceware.org/bugzilla/show_bug.cgi?id=32475