Re: [PATCH] xfs: require an rcu grace period before inode recycle

From: Al Viro <viro@zeniv.linux.org.uk>
To: Dave Chinner <david@fromorbit.com>
Cc: Brian Foster <bfoster@redhat.com>,
	linux-xfs@vger.kernel.org, Ian Kent <raven@themaw.net>,
	rcu@vger.kernel.org
Subject: Re: [PATCH] xfs: require an rcu grace period before inode recycle
Date: Thu, 27 Jan 2022 04:19:34 +0000	[thread overview]
Message-ID: <YfIdVq6R6xEWxy0K@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <20220125224551.GQ59729@dread.disaster.area>

On Wed, Jan 26, 2022 at 09:45:51AM +1100, Dave Chinner wrote:

> Right, background inactivation does not improve performance - it's
> necessary to get the transactions out of the evict() path. All we
> wanted was to ensure that there were no performance degradations as
> a result of background inactivation, not that it was faster.
> 
> If you want to confirm that there is an increase in cold cache
> access when the batch size is increased, cpu profiles with 'perf
> top'/'perf record/report' and CPU cache performance metric reporting
> via 'perf stat -dddd' are your friend. See elsewhere in the thread
> where I mention those things to Paul.

Dave, do you see a plausible way to eventually drop Ian's bandaid?
I'm not asking for that to happen this cycle and for backports Ian's
patch is obviously fine.

What I really want to avoid is the situation when we are stuck with
keeping that bandaid in fs/namei.c, since all ways to avoid seeing
reused inodes would hurt XFS too badly.  And the benchmarks in this
thread do look like that.

Are there any realistic prospects of having xfs_iget() deal with
reuse case by allocating new in-core inode and flipping whatever
references you've got in XFS journalling data structures to the
new copy?  If I understood what you said on IRC correctly, that is...

Again, I'm not asking if it can be done this cycle; having a
realistic path to doing that eventually would be fine by me.