On 30/03/2026 00:13, Collin Funk wrote:
On a AMD Ryzen 7 3700X system:
$ timeout 10 taskset 1 ./src/cat-prev /dev/zero \
| taskset 2 pv -r > /dev/null
[1.84GiB/s]
$ timeout 10 taskset 1 ./src/cat /dev/zero \
| taskset 2 pv -r > /dev/null
[7.92GiB/s]
Very nice.
Did you test on a Power10 system like the NEWS suggests?
(cfarm120.cfarm.net is Power10 BTW)
I noticed a small spelling mistake: intermidate
Adding some debug I see normal operation works as expected:
$ src/cat /dev/null > file
spliced -1
splice status 0
$ src/cat src/cat.c > /dev/null
spliced 27182
spliced 0
splice status 1
$ src/cat src/cat.c > t.c
$ src/cat src/cat.c | cat >/dev/null
spliced 27182
spliced 0
splice status 1
$ strace -o /dev/null -e inject=copy_file_range:error=ENOSYS \
src/cat src/cat.c > t.c
spliced 27182
spliced 0
splice status 1
However this shows a problematic case,
where we don't diagnose errors, either in error message or exit status:
$ strace -o /dev/null -e inject=splice:error=EIO:when=3 \
src/cat /dev/zero > t.c
spliced 524288
spliced -1
splice status 1
I'm thinking we should diagnose all errors if some data is spliced,
and non splice specific errors always?
Also the lseek() fallback worries me for non regular files.
What if splicing from some non seekable device to a file system that doesn't
support splice.
Then the input to intermediate pipe would work but the lseek() could not
restore the bytes.
I wonder could we instead do a probe with read() + vmsplice(),
and the fallback could then use the bytes in the read buffer?
cheers,
Padraig
