linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: linux-fsdevel@vger.kernel.org, jack@suse.com, hch@infradead.org
Subject: Odd locking pattern introduced as part of "nowait aio support"
Date: Tue, 10 Sep 2019 15:33:27 -0700	[thread overview]
Message-ID: <20190910223327.mnegfoggopwqqy33@alap3.anarazel.de> (raw)

Hi,

Especially with buffered io it's fairly easy to hit contention on the
inode lock, during writes. With something like io_uring, it's even
easier, because it currently (but see [1]) farms out buffered writes to
workers, which then can easily contend on the inode lock, even if only
one process submits writes.  But I've seen it in plenty other cases too.

Looking at the code I noticed that several parts of the "nowait aio
support" (cf 728fbc0e10b7f3) series introduced code like:

static ssize_t
ext4_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
{
...
	if (!inode_trylock(inode)) {
		if (iocb->ki_flags & IOCB_NOWAIT)
			return -EAGAIN;
		inode_lock(inode);
	}

isn't trylocking and then locking in a blocking fashion an inefficient
pattern? I.e. I think this should be

	if (iocb->ki_flags & IOCB_NOWAIT) {
		if (!inode_trylock(inode))
			return -EAGAIN;
	}
        else
        	inode_lock(inode);

Obviously this isn't going to improve scalability to a very significant
degree. But not unnecessarily doing two atomic ops on a contended lock
can't hurt scalability either. Also, the current code just seems
confusing.

Am I missing something?

Greetings,

Andres Freund

[1] https://lore.kernel.org/linux-block/20190910164245.14625-1-axboe@kernel.dk/

             reply	other threads:[~2019-09-10 22:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10 22:33 Andres Freund [this message]
2019-09-11  4:04 ` Odd locking pattern introduced as part of "nowait aio support" Dave Chinner
2019-09-11  9:39   ` Andres Freund
2019-09-11 10:19     ` Christoph Hellwig
2019-09-11 10:31     ` Ritesh Harjani
2019-09-11 10:55     ` Goldwyn Rodrigues
2019-09-11 16:45     ` Fix inode sem regression for nowait Goldwyn Rodrigues
2019-09-11 16:45       ` [PATCH 1/3] btrfs: fix inode rwsem regression Goldwyn Rodrigues
2019-09-11 17:21         ` David Sterba
2019-09-11 16:45       ` [PATCH 2/3] ext4: " Goldwyn Rodrigues
2019-09-12  8:52         ` Ritesh Harjani
2019-09-12  9:26           ` Matthew Bobrowski
2019-09-23 10:10         ` Jan Kara
2019-09-23 13:18           ` Theodore Y. Ts'o
2019-09-11 16:45       ` [PATCH 3/3] f2fs: " Goldwyn Rodrigues
2019-09-12  6:17         ` Chao Yu
2019-09-13 19:46         ` Jaegeuk Kim
2019-09-16  1:16           ` Chao Yu
2019-09-11 12:25   ` Odd locking pattern introduced as part of "nowait aio support" Goldwyn Rodrigues

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=20190910223327.mnegfoggopwqqy33@alap3.anarazel.de \
    --to=andres@anarazel.de \
    --cc=hch@infradead.org \
    --cc=jack@suse.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rgoldwyn@suse.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).