[finally Cc'd to fsdevel - should've done that several iterations upthread]

On Wed, Sep 14, 2016 at 01:39:25PM +1000, Nicholas Piggin wrote:

Should not be so bad, but I don't have hard numbers for you. PAGEVEC_SIZE
is 14, and that's conceptually rather similar operation (walk radix tree;
grab pages). OTOH many archs are heavier and do locking and vmas walking etc.

Documentation/features/vm/pte_special/arch-support.txt

But even for those, at 16 entries, the bulk of the cost *should* be hitting
struct page cachelines and refcounting. The rest should mostly stay in cache.

OK...  That's actually important only for vmsplice_to_pipe() and 16-page
array seems to be doing fine there.

Another question, now that you've finally resurfaced: could you reconstruct
the story with page-stealing and breakage(s) thereof that had lead to
commit 485ddb4b9741bafb70b22e5c1f9b4f37dc3e85bd
Author: Nick Piggin [off-list ref]
Date:   Tue Mar 27 08:55:08 2007 +0200

    1/2 splice: dont steal

I realize that it had been 9 years ago, but anything resembling a braindump
would be very welcome.  Note that there is a couple of ->splice_write()
instances that _do_ use ->steal() (fuse_dev_splice_write() and virtio_console
port_fops_splice_write()) and I wonder if they suffer from the same problems;
your commit message is rather short on details, unfortunately.  FUSE one
is especially interesting...