From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Subject: Re: [PATCH RFC] ext4: skip concurrent inode updates in lazytime optimization
Date: Wed, 29 Jan 2020 17:15:46 -0500 [thread overview]
Message-ID: <20200129221546.GB303030@mit.edu> (raw)
In-Reply-To: <158031264567.6836.126132376018905207.stgit@buzz>
On Wed, Jan 29, 2020 at 06:44:05PM +0300, Konstantin Khlebnikov wrote:
> Function ext4_update_other_inodes_time() implements optimization which
> opportunistically updates times for inodes within same inode table block.
>
> For now concurrent inode lookup by number does not scale well because
> inode hash table is protected with single spinlock. It could become very
> hot at concurrent writes to fast nvme when inode cache has enough inodes.
>
> Probably someday inode hash will become searchable under RCU.
> (see linked patchset by David Howells)
>
> Let's skip concurrent updates instead of wasting cpu time at spinlock.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Link: https://lore.kernel.org/lkml/155620449631.4720.8762546550728087460.stgit@warthog.procyon.org.uk/
Hmm.... I wonder what Al thinks of adding a varaint of
find_inode_nowait() which uses tries to grab the inode_hash_lock()
using a trylock, and returns ERR_PTR(-EAGAIN) if the attempt to grab
the lock fails.
This might be better since it will prevent other conflicts between
ext4_update_other_inodes_time() and other attempts to lookup inodes
which can't be skipped if things are busy.
- Ted
prev parent reply other threads:[~2020-01-29 22:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 15:44 [PATCH RFC] ext4: skip concurrent inode updates in lazytime optimization Konstantin Khlebnikov
2020-01-29 19:53 ` Andreas Dilger
2020-01-29 22:15 ` Theodore Y. Ts'o [this message]
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=20200129221546.GB303030@mit.edu \
--to=tytso@mit.edu \
--cc=dhowells@redhat.com \
--cc=dmtrmonakhov@yandex-team.ru \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.