All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH RFC 0/4] xfs: track and skip realloc of busy inodes
Date: Thu, 17 Feb 2022 12:25:14 -0500	[thread overview]
Message-ID: <20220217172518.3842951-1-bfoster@redhat.com> (raw)

Hi all,

This RFC cleans up some of the previous experimentation I was doing and
turns it into more of a usable prototype. The first couple of patches
are pretty straightforward. Patch 1 is a variant of the previously
posted patch to stamp inodes with a grace period at destroy time. Patch
2 tags inodes with still pending grace periods as busy in the radix
tree. Patch 3 is a quick hack to allow the inode selection algorithms to
fall back to chunk allocation and retry. Patch 4 updates the finobt
selection algorithms to filter records with busy inodes and fall back to
chunk allocation until a usable record is found.

The current status of this work is that it should be functionally
effective in terms of preventing allocation of busy inodes. This can be
measured by lack of RCU stalls, also identified by the tracepoint added
in patch 1 (this should probably assert or warn in the new inode
allocation recycle case since the goal is for that to never happen).
Performance is significantly improved from previous tests with only
patch 1, but still reduced from mainline. However, reduced performance
is to be expected because mainline unsafely reuses inodes rather
aggressively. Therefore, the goal is for something that
preserves/maintains closer to pure inode allocation performance.

I expect that the allocation algorithm can be adapted further to provide
incremental improvements in performance. The first and most obvious step
is to defer freeing of inode chunks to the background to mitigate
repetitive finobt search failure -> new chunk allocation retry sequences
that may be seen with the current prototype. Other improvements may be
possible to make the search algorithm itself more effective. I'm sending
this as a prototype for early feedback and thoughts on approach,
prospective improvements, etc. Thoughts, reviews, flames appreciated.

Brian

Brian Foster (4):
  xfs: require an rcu grace period before inode recycle
  xfs: tag reclaimable inodes with pending RCU grace periods as busy
  xfs: crude chunk allocation retry mechanism
  xfs: skip busy inodes on finobt inode allocation

 fs/xfs/libxfs/xfs_ialloc.c | 99 +++++++++++++++++++++++++++++++++++---
 fs/xfs/xfs_icache.c        | 55 +++++++++++++++++----
 fs/xfs/xfs_inode.h         |  3 +-
 fs/xfs/xfs_trace.h         |  8 ++-
 4 files changed, 146 insertions(+), 19 deletions(-)

-- 
2.31.1


             reply	other threads:[~2022-02-17 17:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17 17:25 Brian Foster [this message]
2022-02-17 17:25 ` [PATCH RFC 1/4] xfs: require an rcu grace period before inode recycle Brian Foster
2022-02-17 17:25 ` [PATCH RFC 2/4] xfs: tag reclaimable inodes with pending RCU grace periods as busy Brian Foster
2022-02-17 23:16   ` Dave Chinner
2022-02-18 14:19     ` Brian Foster
2022-02-17 17:25 ` [PATCH RFC 3/4] xfs: crude chunk allocation retry mechanism Brian Foster
2022-02-17 23:20   ` Dave Chinner
2022-02-18 14:21     ` Brian Foster
2022-02-18 22:54       ` Dave Chinner
2022-02-20 18:48         ` Brian Foster
2022-02-23  7:00           ` Dave Chinner
2022-02-28 21:45             ` Brian Foster
2022-02-28 22:55               ` Dave Chinner
2022-03-01 15:05                 ` Brian Foster
2022-02-17 17:25 ` [PATCH RFC 4/4] xfs: skip busy inodes on finobt inode allocation 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=20220217172518.3842951-1-bfoster@redhat.com \
    --to=bfoster@redhat.com \
    --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 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.