From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 28/28] xfs: rework unreferenced inode lookups
Date: Mon, 18 Nov 2019 12:00:47 +1100 [thread overview]
Message-ID: <20191118010047.GS4614@dread.disaster.area> (raw)
In-Reply-To: <20191115172600.GC55854@bfoster>
On Fri, Nov 15, 2019 at 12:26:00PM -0500, Brian Foster wrote:
> On Fri, Nov 15, 2019 at 09:16:02AM +1100, Dave Chinner wrote:
> > On Wed, Nov 06, 2019 at 05:18:46PM -0500, Brian Foster wrote:
> > If so, most of this patch will go away....
> >
> > > > + * attached to the buffer so we don't need to do anything more here.
> > > > */
> > > > - if (ip != free_ip) {
> > > > - if (!xfs_ilock_nowait(ip, XFS_ILOCK_EXCL)) {
> > > > - rcu_read_unlock();
> > > > - delay(1);
> > > > - goto retry;
> > > > - }
> > > > -
> > > > - /*
> > > > - * Check the inode number again in case we're racing with
> > > > - * freeing in xfs_reclaim_inode(). See the comments in that
> > > > - * function for more information as to why the initial check is
> > > > - * not sufficient.
> > > > - */
> > > > - if (ip->i_ino != inum) {
> > > > + if (__xfs_iflags_test(ip, XFS_ISTALE)) {
> > >
> > > Is there a correctness reason for why we move the stale check to under
> > > ilock (in both iflush/ifree)?
> >
> > It's under the i_flags_lock, and so I moved it up under the lookup
> > hold of the i_flags_lock so we don't need to cycle it again.
> >
>
> Yeah, but in both cases it looks like it moved to under the ilock as
> well, which comes after i_flags_lock. IOW, why grab ilock for stale
> inodes when we're just going to skip them?
Because I was worrying about serialising against reclaim before
changing the state of the inode. i.e. if the inode has already been
isolated by not yet disposed of, we shouldn't touch the inode state
at all. Serialisation against reclaim in this patch is via the
ILOCK, hence we need to do that before setting ISTALE....
IOWs, ISTALE is not protected by ILOCK, we just can't modify the
inode state until after we've gained the ILOCK to protect against
reclaim....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-11-18 1:00 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-31 23:45 [PATCH 00/28] mm, xfs: non-blocking inode reclaim Dave Chinner
2019-10-31 23:45 ` [PATCH 01/28] xfs: Lower CIL flush limit for large logs Dave Chinner
2019-10-31 23:45 ` [PATCH 02/28] xfs: Throttle commits on delayed background CIL push Dave Chinner
2019-11-01 12:04 ` Brian Foster
2019-11-01 21:40 ` Dave Chinner
2019-11-04 22:48 ` Darrick J. Wong
2019-10-31 23:45 ` [PATCH 03/28] xfs: don't allow log IO to be throttled Dave Chinner
2019-10-31 23:45 ` [PATCH 04/28] xfs: Improve metadata buffer reclaim accountability Dave Chinner
2019-11-01 12:05 ` Brian Foster
2019-11-04 23:21 ` Darrick J. Wong
2019-10-31 23:45 ` [PATCH 05/28] xfs: correctly acount for reclaimable slabs Dave Chinner
2019-10-31 23:45 ` [PATCH 06/28] xfs: factor common AIL item deletion code Dave Chinner
2019-11-04 23:16 ` Darrick J. Wong
2019-10-31 23:45 ` [PATCH 07/28] xfs: tail updates only need to occur when LSN changes Dave Chinner
2019-11-04 23:18 ` Darrick J. Wong
2019-10-31 23:45 ` [PATCH 08/28] xfs: factor inode lookup from xfs_ifree_cluster Dave Chinner
2019-11-01 12:05 ` Brian Foster
2019-11-04 23:20 ` Darrick J. Wong
2019-10-31 23:45 ` [PATCH 09/28] mm: directed shrinker work deferral Dave Chinner
2019-11-04 15:25 ` Brian Foster
2019-11-14 20:49 ` Dave Chinner
2019-11-15 17:21 ` Brian Foster
2019-11-18 0:49 ` Dave Chinner
2019-11-19 15:12 ` Brian Foster
2019-10-31 23:46 ` [PATCH 10/28] shrinkers: use defer_work for GFP_NOFS sensitive shrinkers Dave Chinner
2019-10-31 23:46 ` [PATCH 11/28] mm: factor shrinker work calculations Dave Chinner
2019-11-02 10:55 ` kbuild test robot
2019-11-04 15:29 ` Brian Foster
2019-11-14 20:59 ` Dave Chinner
2019-10-31 23:46 ` [PATCH 12/28] shrinker: defer work only to kswapd Dave Chinner
2019-11-04 15:29 ` Brian Foster
2019-11-14 21:11 ` Dave Chinner
2019-11-15 17:23 ` Brian Foster
2019-10-31 23:46 ` [PATCH 13/28] shrinker: clean up variable types and tracepoints Dave Chinner
2019-11-04 15:30 ` Brian Foster
2019-10-31 23:46 ` [PATCH 14/28] mm: reclaim_state records pages reclaimed, not slabs Dave Chinner
2019-11-04 19:58 ` Brian Foster
2019-10-31 23:46 ` [PATCH 15/28] mm: back off direct reclaim on excessive shrinker deferral Dave Chinner
2019-11-04 19:58 ` Brian Foster
2019-11-14 21:28 ` Dave Chinner
2019-10-31 23:46 ` [PATCH 16/28] mm: kswapd backoff for shrinkers Dave Chinner
2019-11-04 19:58 ` Brian Foster
2019-11-14 21:41 ` Dave Chinner
2019-10-31 23:46 ` [PATCH 17/28] xfs: synchronous AIL pushing Dave Chinner
2019-11-05 17:05 ` Brian Foster
2019-10-31 23:46 ` [PATCH 18/28] xfs: don't block kswapd in inode reclaim Dave Chinner
2019-10-31 23:46 ` [PATCH 19/28] xfs: reduce kswapd blocking on inode locking Dave Chinner
2019-11-05 17:05 ` Brian Foster
2019-10-31 23:46 ` [PATCH 20/28] xfs: kill background reclaim work Dave Chinner
2019-11-05 17:05 ` Brian Foster
2019-10-31 23:46 ` [PATCH 21/28] xfs: use AIL pushing for inode reclaim IO Dave Chinner
2019-11-05 17:06 ` Brian Foster
2019-10-31 23:46 ` [PATCH 22/28] xfs: remove mode from xfs_reclaim_inodes() Dave Chinner
2019-10-31 23:46 ` [PATCH 23/28] xfs: track reclaimable inodes using a LRU list Dave Chinner
2019-10-31 23:46 ` [PATCH 24/28] xfs: reclaim inodes from the LRU Dave Chinner
2019-11-06 17:21 ` Brian Foster
2019-11-14 21:51 ` Dave Chinner
2019-10-31 23:46 ` [PATCH 25/28] xfs: remove unusued old inode reclaim code Dave Chinner
2019-11-06 17:21 ` Brian Foster
2019-10-31 23:46 ` [PATCH 26/28] xfs: use xfs_ail_push_all in xfs_reclaim_inodes Dave Chinner
2019-11-06 17:22 ` Brian Foster
2019-11-14 21:53 ` Dave Chinner
2019-10-31 23:46 ` [PATCH 27/28] rwsem: introduce down/up_write_non_owner Dave Chinner
2019-10-31 23:46 ` [PATCH 28/28] xfs: rework unreferenced inode lookups Dave Chinner
2019-11-06 22:18 ` Brian Foster
2019-11-14 22:16 ` Dave Chinner
2019-11-15 13:13 ` Christoph Hellwig
2019-11-15 17:26 ` Brian Foster
2019-11-18 1:00 ` Dave Chinner [this message]
2019-11-19 15:13 ` Brian Foster
2019-11-19 21:18 ` Dave Chinner
2019-11-20 12:42 ` Brian Foster
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=20191118010047.GS4614@dread.disaster.area \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.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
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).