On Fri, 14 Feb 2025 at 05:36, Charlie Jenkins <charlie@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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
