Hi,
An upcoming Linux kernel release is likely to neuter vmsplice [1]. It is
possible (likely?) that splice and tee get similar treatments in the
future [2].
I was curious to see the performance of 'yes' from coreutils-9.11 with
the vmsplice changes, so I built a kernel and tested it for myself. I
CC'ed Pádraig on my mail to kernel.org but realized I should probably
share the results here as well [3].
Here is the performance on my Fedora kernel:
$ uname -r
7.0.10-201.fc44.x86_64
$ yes --version | head -n 1
yes (GNU coreutils) 9.11.50-157bd
$ timeout 1m taskset 1 yes | taskset 2 pv -r > /dev/null
[36.9GiB/s]
Here is the performance after the vmsplice changes, using a kernel
configuration based on that Fedora kernel:
$ uname -r
7.1.0-rc1+
$ yes --version | head -n 1
yes (GNU coreutils) 9.11.50-157bd
$ timeout 1m taskset 1 yes | taskset 2 pv -r > /dev/null
[3.41GiB/s]
So, 'yes' using vmsplice is 10 times slower with that change. We are
better of using read and write in that case:
$ /bin/yes --version | head -n 1
yes (GNU coreutils) 9.10
$ timeout 1m taskset 1 /bin/yes | taskset 2 pv -r > /dev/null
[4.55GiB/s]
I trust that that kernel developers are more qualified than I to assess
and understand the security benefits of this change. However, it is a
bit unfortunate that we only got to experience 'yes' being fast
(relative to it's previous definition of fast) for a month.
I guess the point of this email is just to give a heads up that we might
need to revert those changes, assuming those patches are
merged. Currently they are in the vfs tree for 7.2 [4]. Normal splice
and tee are okay for now, at least.
Collin
[1] https://lore.kernel.org/all/[email protected]/
[2]
https://lore.kernel.org/all/CAHk-=wifx_rrdjrgndnoqe-usptaukuxkrmupuvdp5bocbw...@mail.gmail.com/
[3] https://lore.kernel.org/all/[email protected]/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
