Pádraig Brady <[email protected]> writes: > 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 forgot to test it there after fixing the patch. > I noticed a small spelling mistake: intermidate Nice catch. Not sure why codespell didn't complain about it. > 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 Thanks, I'll have a look at that. > 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? My main concern when writing it was that the first splice may succeed, but then the second splice might fail because standard output is a file on a file system that does not support splice. In that case, I think it would be poor behavior to print an error; we should still fall back to read and write. I'll think about it some more. Collin
