Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: chenqiwu <qiwuchen55@gmail.com>
To: Bernd Schubert <bernd.schubert@fastmail.fm>
Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org,
	chenqiwu <chenqiwu@xiaomi.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH] fuse: fix inode rwsem regression
Date: Mon, 3 Feb 2020 11:20:12 +0800
Message-ID: <20200203032012.GA11846@cqw-OptiPlex-7050> (raw)
In-Reply-To: <aafd8abf-832b-6348-7b74-4d65451a1eb6@fastmail.fm>

On Sun, Feb 02, 2020 at 10:18:58PM +0100, Bernd Schubert wrote:
> 
> 
> On 2/2/20 3:08 AM, chenqiwu wrote:
> > On Sun, Feb 02, 2020 at 12:09:50AM +0100, Bernd Schubert wrote:
> >>
> >>
> >> On 2/1/20 6:49 AM, qiwuchen55@gmail.com wrote:
> >>> From: chenqiwu <chenqiwu@xiaomi.com>
> >>>
> >>> Apparently our current rwsem code doesn't like doing the trylock, then
> >>> lock for real scheme.  So change our direct write method to just do the
> >>> trylock for the RWF_NOWAIT case.
> >>> This seems to fix AIM7 regression in some scalable filesystems upto ~25%
> >>> in some cases. Claimed in commit 942491c9e6d6 ("xfs: fix AIM7 regression")
> >>>
> >>> Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
> >>> ---
> >>>  fs/fuse/file.c | 8 +++++++-
> >>>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> >>> index ce71538..ac16994 100644
> >>> --- a/fs/fuse/file.c
> >>> +++ b/fs/fuse/file.c
> >>> @@ -1529,7 +1529,13 @@ static ssize_t fuse_direct_write_iter(struct kiocb *iocb, struct iov_iter *from)
> >>>  	ssize_t res;
> >>>  
> >>>  	/* Don't allow parallel writes to the same file */
> >>> -	inode_lock(inode);
> >>> +	if (iocb->ki_flags & IOCB_NOWAIT) {
> >>> +		if (!inode_trylock(inode))
> >>> +			return -EAGAIN;
> >>> +	} else {
> >>> +		inode_lock(inode);
> >>> +	}
> >>> +
> >>>  	res = generic_write_checks(iocb, from);
> >>>  	if (res > 0) {
> >>>  		if (!is_sync_kiocb(iocb) && iocb->ki_flags & IOCB_DIRECT) {
> >>>
> >>
> >>
> >> I would actually like to ask if we can do something about this lock
> >> altogether. Replace it with a range lock?  This very lock badly hurts
> >> fuse shared file performance and maybe I miss something, but it should
> >> be needed only for writes/reads going into the same file?
> >>
> > I think replacing the internal inode rwsem with a range lock maybe not
> > a good idea, because it may cause potential block for different writes/reads
> > routes when this range lock is owned by someone. Using internal inode rwsem
> > can avoid this range racy.
> > 
> 
> So your 2nd patch changes to rw-locks and should solve low read
> direct-io performance, but single shared file writes is still an issue.
> For network file systems it also common to globally enforce fuse
> direct-io to reduce/avoid cache coherency issues - the application
> typically doesn't ask for that on its own. And that is where this lock
> is badly hurting.  Hmm, maybe we should differentiate between
> fuse-internal direct-io and application direct-io requests here? Or we
> need a range lock,that supports shared readers (I haven't looked at any
> of the proposed range lock patches yet (non has landed yet, right?).
>
There is a recent fix for ext4 and we can evaluate and apply it to fuse
filesytem for solving low dio-write performance.
aa9714d0e(ext4: Start with shared i_rwsem in case of DIO instead of exclusive)

Thanks!
Qiwu

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01  5:49 qiwuchen55
2020-02-01 15:47 ` Matthew Wilcox
2020-02-01 23:09 ` Bernd Schubert
2020-02-02  2:08   ` chenqiwu
2020-02-02 21:18     ` Bernd Schubert
2020-02-03  3:20       ` chenqiwu [this message]
2020-02-13  9:50       ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200203032012.GA11846@cqw-OptiPlex-7050 \
    --to=qiwuchen55@gmail.com \
    --cc=bernd.schubert@fastmail.fm \
    --cc=chenqiwu@xiaomi.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git