From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:49168 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753208AbcIRFet (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Sun, 18 Sep 2016 01:34:49 -0400
Date: Sun, 18 Sep 2016 06:33:52 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Dave Chinner <david@fromorbit.com>,
        CAI Qian <caiqian@redhat.com>,
        linux-xfs <linux-xfs@vger.kernel.org>, xfs@oss.sgi.com,
        Jens Axboe <axboe@kernel.dk>, linux-fsdevel@vger.kernel.org
Subject: Re: xfs_file_splice_read: possible circular locking dependency
 detected
Message-ID: <20160918053337.GA32207@ZenIV.linux.org.uk>
References: <20160908235521.GL2356@ZenIV.linux.org.uk>
 <20160909015324.GD30056@dastard>
 <CA+55aFzohsUXj_3BeFNr2t50Wm=G+7toRDEz=Tk7VJqP3n1hXQ@mail.gmail.com>
 <CA+55aFxrqCng2Qxasc9pyMrKUGFjo==fEaFT1vkH9Lncte3RgQ@mail.gmail.com>
 <20160909023452.GO2356@ZenIV.linux.org.uk>
 <CA+55aFwHQMjO4-vtfB9-ytc=o+DRo-HXVGckvXLboUxgpwb7_g@mail.gmail.com>
 <20160909221945.GQ2356@ZenIV.linux.org.uk>
 <CA+55aFzTOOB6oEVaaGD0N7Uznk-W9+ULPwzsxS_L_oZqGVSeLA@mail.gmail.com>
 <20160914031648.GB2356@ZenIV.linux.org.uk>
 <20160914133925.2fba4629@roar.ozlabs.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160914133925.2fba4629@roar.ozlabs.ibm.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

[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@suse.de>
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...