Message ID | 20250315172319.16770-1-sidong.yang@furiosa.ai (mailing list archive) |
---|---|
Headers | show |
Series | introduce io_uring_cmd_import_fixed_vec | expand |
On 3/15/25 17:23, Sidong Yang wrote: > This patche series introduce io_uring_cmd_import_vec. With this function, > Multiple fixed buffer could be used in uring cmd. It's vectored version > for io_uring_cmd_import_fixed(). Also this patch series includes a usage > for new api for encoded read/write in btrfs by using uring cmd. > > There was approximately 10 percent of performance improvements through benchmark. > The benchmark code is in > https://github.com/SidongYang/btrfs-encoded-io-test/blob/main/main.c > > ./main -l > Elapsed time: 0.598997 seconds > ./main -l -f > Elapsed time: 0.540332 seconds It's probably precise, but it's usually hard to judge about performance from such short runs. Mark, do we have some benchmark for the io_uring cmd?
On 16/3/25 07:22, Pavel Begunkov wrote: > > > On 3/15/25 17:23, Sidong Yang wrote: >> This patche series introduce io_uring_cmd_import_vec. With this function, >> Multiple fixed buffer could be used in uring cmd. It's vectored version >> for io_uring_cmd_import_fixed(). Also this patch series includes a usage >> for new api for encoded read/write in btrfs by using uring cmd. >> >> There was approximately 10 percent of performance improvements through >> benchmark. >> The benchmark code is in >> https://github.com/SidongYang/btrfs-encoded-io-test/blob/main/main.c >> ./main -l >> Elapsed time: 0.598997 seconds >> ./main -l -f >> Elapsed time: 0.540332 seconds > > It's probably precise, but it's usually hard to judge about > performance from such short runs. Mark, do we have some benchmark > for the io_uring cmd? Unfortunately not. My plan was to plug it in to btrfs-receive and to use that as a benchmark, but it turned out that the limiting factor there was the dentry locking. Sidong, Pavel is right - your figures would be more useful if you ran it 1,000 times or so. Mark