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: Re: [PATCH 0/6] xfs: CPU usage optimizations for realtime allocator
Date: Thu, 6 Jul 2023 14:39:08 -0700	[thread overview]
Message-ID: <ZKc0fCe9AtkRtDLB@telecaster> (raw)
In-Reply-To: <cover.1687296675.git.osandov@osandov.com>

On Tue, Jun 20, 2023 at 02:32:10PM -0700, Omar Sandoval wrote:
> 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(-)

Gentle ping.

  parent reply	other threads:[~2023-07-06 21:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-20 21:32 [PATCH 0/6] xfs: CPU usage optimizations for realtime allocator Omar Sandoval
2023-06-20 21:32 ` [PATCH 1/6] xfs: cache last bitmap block in " 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 ` Omar Sandoval [this message]
2023-07-07  0:36   ` [PATCH 0/6] xfs: CPU usage optimizations for realtime allocator 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=ZKc0fCe9AtkRtDLB@telecaster \
    --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.