All of lore.kernel.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: linux-xfs@vger.kernel.org
Cc: "Darrick J . Wong" <djwong@kernel.org>,
	kernel-team@fb.com, Prashant Nema <pnema@fb.com>
Subject: [PATCH 0/6] xfs: CPU usage optimizations for realtime allocator
Date: Tue, 20 Jun 2023 14:32:10 -0700	[thread overview]
Message-ID: <cover.1687296675.git.osandov@osandov.com> (raw)

Hello,

Our distributed storage system uses XFS's realtime device support as a
way to split an XFS filesystem between an SSD and an HDD -- we configure
the HDD as the realtime device so that metadata goes on the SSD and data
goes on the HDD.

We've been running this in production for a few years now, so we have
some fairly fragmented filesystems. This has exposed various CPU
inefficiencies in the realtime allocator. These became even worse when
we experimented with using XFS_XFLAG_EXTSIZE to force files to be
allocated contiguously.

This series adds several optimizations that don't change the realtime
allocator's decisions, but make them happen more efficiently, mainly by
avoiding redundant work. We've tested these in production and measured
~10% lower CPU utilization. Furthermore, it made it possible to use
XFS_XFLAG_EXTSIZE to force contiguous allocations -- without these
patches, our most fragmented systems would become unresponsive due to
high CPU usage in the realtime allocator, but with them, CPU utilization
is actually ~4-6% lower than before, and disk I/O utilization is 15-20%
lower.

Patches 2 and 3 are preparations for later optimizations; the remaining
patches are the optimizations themselves.

This is based on Linus' tree as of today (commit
692b7dc87ca6d55ab254f8259e6f970171dc9d01).

Thanks!

Omar Sandoval (6):
  xfs: cache last bitmap block in realtime allocator
  xfs: invert the realtime summary cache
  xfs: return maximum free size from xfs_rtany_summary()
  xfs: limit maxlen based on available space in
    xfs_rtallocate_extent_near()
  xfs: don't try redundant allocations in xfs_rtallocate_extent_near()
  xfs: don't look for end of extent further than necessary in
    xfs_rtallocate_extent_near()

 fs/xfs/libxfs/xfs_rtbitmap.c | 173 ++++++++++++++--------------
 fs/xfs/xfs_mount.h           |   6 +-
 fs/xfs/xfs_rtalloc.c         | 215 ++++++++++++++++-------------------
 fs/xfs/xfs_rtalloc.h         |  28 +++--
 4 files changed, 207 insertions(+), 215 deletions(-)

-- 
2.41.0


             reply	other threads:[~2023-06-20 21:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 21:32 Omar Sandoval [this message]
2023-06-20 21:32 ` [PATCH 1/6] xfs: cache last bitmap block in realtime allocator Omar Sandoval
2023-07-12 18:29   ` Darrick J. Wong
2023-07-17 18:18     ` Omar Sandoval
2023-08-01 22:48       ` Darrick J. Wong
2023-06-20 21:32 ` [PATCH 2/6] xfs: invert the realtime summary cache Omar Sandoval
2023-07-12 22:40   ` Darrick J. Wong
2023-07-17 19:54     ` Omar Sandoval
2023-08-01 23:17       ` Darrick J. Wong
2023-06-20 21:32 ` [PATCH 3/6] xfs: return maximum free size from xfs_rtany_summary() Omar Sandoval
2023-07-12 22:44   ` Darrick J. Wong
2023-06-20 21:32 ` [PATCH 4/6] xfs: limit maxlen based on available space in xfs_rtallocate_extent_near() Omar Sandoval
2023-07-12 23:01   ` Darrick J. Wong
2023-07-17 20:33     ` Omar Sandoval
2023-06-20 21:32 ` [PATCH 5/6] xfs: don't try redundant allocations " Omar Sandoval
2023-07-12 23:34   ` Darrick J. Wong
2023-07-17 21:06     ` Omar Sandoval
2023-07-31 20:58       ` Omar Sandoval
2023-08-01 23:00       ` Darrick J. Wong
2023-06-20 21:32 ` [PATCH 6/6] xfs: don't look for end of extent further than necessary " Omar Sandoval
2023-08-01 23:40   ` Darrick J. Wong
2023-07-06 21:39 ` [PATCH 0/6] xfs: CPU usage optimizations for realtime allocator Omar Sandoval
2023-07-07  0:36   ` Dave Chinner

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=cover.1687296675.git.osandov@osandov.com \
    --to=osandov@osandov.com \
    --cc=djwong@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=pnema@fb.com \
    /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.