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.
