[PATCH V2] raid6: Add RISC-V SIMD syndrome and recovery calculations

[Chunyan Zhang]

On Fri, 14 Feb 2025 at 05:36, Charlie Jenkins <charlie at rivosinc.com> wrote:
>
> On Tue, Feb 11, 2025 at 05:59:26PM +0800, Chunyan Zhang wrote:
> > On Tue, 28 Jan 2025 at 06:34, Charlie Jenkins <charlie at rivosinc.com> wrote:
> > >
> > > On Mon, Jan 27, 2025 at 09:39:11AM +0100, Paul Menzel wrote:
> > > > Dear Chunyan,
> > > >
> > > >
> > > > Thank you for the patch.
> > > >
> > > >
> > > > Am 27.01.25 um 07:15 schrieb Chunyan Zhang:
> > > > > The assembly is originally based on the ARM NEON and int.uc, but uses
> > > > > RISC-V vector instructions to implement the RAID6 syndrome and
> > > > > recovery calculations.
> > > > >
> > > > > Results on QEMU running with the option "-icount shift=0":
> > > > >
> > > > >    raid6: rvvx1    gen()  1008 MB/s
> > > > >    raid6: rvvx2    gen()  1395 MB/s
> > > > >    raid6: rvvx4    gen()  1584 MB/s
> > > > >    raid6: rvvx8    gen()  1694 MB/s
> > > > >    raid6: int64x8  gen()   113 MB/s
> > > > >    raid6: int64x4  gen()   116 MB/s
> > > > >    raid6: int64x2  gen()   272 MB/s
> > > > >    raid6: int64x1  gen()   229 MB/s
> > > > >    raid6: using algorithm rvvx8 gen() 1694 MB/s
> > > > >    raid6: .... xor() 1000 MB/s, rmw enabled
> > > > >    raid6: using rvv recovery algorithm
> > > >
> > > > How did you start QEMU and on what host did you run it? Does it change
> > > > between runs? (For me these benchmark values were very unreliable in the
> > > > past on x86 hardware.)
> > >
> > > I reported dramatic gains on vector as well in this response [1]. Note
> > > that these gains are only present when using the QEMU option "-icount
> > > shift=0" vector becomes dramatically more performant. Without this
> > > option we do not see a performance gain on QEMU. However riscv vector is
> > > known to not be less optimized on QEMU so having vector be less
> > > performant on some QEMU configurations is not necessarily representative
> > > of hardware implementations.
> > >
> > >
> > > My full qemu command is (running on x86 host):
> > >
> > > qemu-system-riscv64 -nographic -m 1G -machine virt -smp 1\
> > >     -kernel arch/riscv/boot/Image \
> > >     -append "root=/dev/vda rw earlycon console=ttyS0" \
> > >     -drive file=rootfs.ext2,format=raw,id=hd0,if=none \
> > >     -bios default -cpu rv64,v=true,vlen=256,vext_spec=v1.0 \
> > >     -device virtio-blk-device,drive=hd0
> > >
> > > This is with version 9.2.0.
> > >
> > >
> > > I am also facing this issue when executing this:
> > >
> > > raid6: rvvx1    gen()   717 MB/s
> > > raid6: rvvx2    gen()   734 MB/s
> > > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
> > >
> > > Only rvvx4 is failing. I applied this patch to 6.13.
> >
> > I used your command to run but no issue on my side (x86 host, qemu
> > version is 9.2.0, kernel 6.13 too):
> >
> > qemu-system-riscv64 -nographic -m 1G -machine virt -smp 1 -icount shift=0 \
> >         -kernel arch/riscv/boot/Image   \
> >         -append "rootwait root=/dev/vda ro"     \
> >         -drive file=rootfs.ext4,format=raw,id=hd0 \
> >         -bios default -cpu rv64,v=true,vlen=256,vext_spec=v1.0 \
> >         -device virtio-blk-device,drive=hd0
>
> I am able to reproduce it with this defconfig:
>
> CONFIG_SYSVIPC=y
> CONFIG_NO_HZ_IDLE=y
> CONFIG_HIGH_RES_TIMERS=y
> CONFIG_BPF_SYSCALL=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_NAMESPACES=y
> CONFIG_USER_NS=y
> CONFIG_CHECKPOINT_RESTORE=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_EXPERT=y
> # CONFIG_SYSFS_SYSCALL is not set
> CONFIG_PROFILING=y
> CONFIG_SMP=y
> CONFIG_CPU_FREQ=y
> CONFIG_CPU_FREQ_STAT=y
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> CONFIG_CPUFREQ_DT=y
> CONFIG_JUMP_LABEL=y
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_MTD=y
> CONFIG_MTD_BLOCK=y
> CONFIG_MTD_CFI=y
> CONFIG_MTD_CFI_ADV_OPTIONS=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_VIRTIO_BLK=y
> CONFIG_MD=y
> CONFIG_BLK_DEV_MD=y
> CONFIG_MD_RAID456=y
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_DW=y
> CONFIG_SERIAL_OF_PLATFORM=y
> CONFIG_SERIAL_SIFIVE=y
> CONFIG_SERIAL_SIFIVE_CONSOLE=y
> CONFIG_VIRTIO_CONSOLE=y
> CONFIG_HW_RANDOM_VIRTIO=y
> CONFIG_PINCTRL=y
> CONFIG_GPIOLIB=y
> CONFIG_GPIO_DWAPB=y
> CONFIG_GPIO_SIFIVE=y
> CONFIG_SOUND=y
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_DRV_GOLDFISH=y
> CONFIG_DMADEVICES=y
> CONFIG_DW_AXI_DMAC=y
> CONFIG_VIRTIO_BALLOON=y
> CONFIG_VIRTIO_INPUT=y
> CONFIG_VIRTIO_MMIO=y
> CONFIG_GOLDFISH=y
> CONFIG_MAILBOX=y
> CONFIG_RPMSG_CTRL=y
> CONFIG_RPMSG_VIRTIO=y
> CONFIG_PM_DEVFREQ=y
> CONFIG_IIO=y
> CONFIG_LIBNVDIMM=y
> CONFIG_EXT4_FS=y
> CONFIG_EXT4_FS_POSIX_ACL=y
> CONFIG_EXT4_FS_SECURITY=y
> CONFIG_AUTOFS_FS=y
> CONFIG_ISO9660_FS=y
> CONFIG_JOLIET=y
> CONFIG_ZISOFS=y
> CONFIG_MSDOS_FS=y
> CONFIG_VFAT_FS=y
> CONFIG_PRINTK_TIME=y
> CONFIG_SCHED_STACK_END_CHECK=y
> # CONFIG_RCU_TRACE is not set
> # CONFIG_FTRACE is not set
> # CONFIG_RUNTIME_TESTING_MENU is not set
>
> I took the riscv/defconfig and added MD_RAID456 and it's dependencies.
> So that the message wasn't too long I started removing some unnecessary
> configs. Try this out and let me know if you encounter the issue.

I took the riscv/defconfig and set MD_RAID456=y, but didn't see this issue.
Since RAID6_PQ is selected by MD_RAID456, so RAID6_PQ=y, I got the
raid6 test result during kernel init.

[    0.317147] raid6: rvvx1    gen()    45 MB/s
[    0.390800] raid6: rvvx2    gen()    45 MB/s
[    0.459435] raid6: rvvx4    gen()    45 MB/s
[    0.527651] raid6: rvvx8    gen()    44 MB/s
[    0.596123] raid6: int64x8  gen()  1232 MB/s
[    0.664686] raid6: int64x4  gen()  2728 MB/s
[    0.733291] raid6: int64x2  gen()  3405 MB/s
[    0.801836] raid6: int64x1  gen()  2730 MB/s
[    0.801895] raid6: using algorithm int64x2 gen() 3405 MB/s
[    0.870379] raid6: .... xor() 493 MB/s, rmw enabled

Thanks,
Chunyan