[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 <npiggin@xxxxxxx>
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...
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
