All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-xfs@vger.kernel.org, kernel-team@fb.com,
	Prashant Nema <pnema@fb.com>
Subject: Re: [PATCH 6/6] xfs: don't look for end of extent further than necessary in xfs_rtallocate_extent_near()
Date: Tue, 1 Aug 2023 16:40:12 -0700	[thread overview]
Message-ID: <20230801234012.GD11336@frogsfrogsfrogs> (raw)
In-Reply-To: <554f3ce85edca54d14cc1e1b22c4207a3e8f36a7.1687296675.git.osandov@osandov.com>

On Tue, Jun 20, 2023 at 02:32:16PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
> 
> As explained in the previous commit, xfs_rtallocate_extent_near() looks
> for the end of a free extent when searching backwards from the target
> bitmap block. Since the previous commit, it searches from the last
> bitmap block it checked to the bitmap block containing the start of the
> extent.
> 
> This may still be more than necessary, since the free extent may not be
> that long. We know the maximum size of the free extent from the realtime
> summary. Use that to compute how many bitmap blocks we actually need to
> check.
> 
> Signed-off-by: Omar Sandoval <osandov@fb.com>
> ---
>  fs/xfs/xfs_rtalloc.c | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
> index 4d9d0be2e616..2e2eb7c4a648 100644
> --- a/fs/xfs/xfs_rtalloc.c
> +++ b/fs/xfs/xfs_rtalloc.c
> @@ -517,12 +517,29 @@ xfs_rtallocate_extent_near(
>  			 * On the negative side of the starting location.
>  			 */
>  			else {		/* i < 0 */
> +				int maxblocks;
> +
>  				/*
> -				 * Loop backwards through the bitmap blocks from
> -				 * where we last checked up to where we are now.
> -				 * There should be an extent which ends in this
> -				 * bitmap block and is long enough.
> +				 * Loop backwards to find the end of the extent
> +				 * we found in the realtime summary.
> +				 *
> +				 * maxblocks is the maximum possible number of
> +				 * bitmap blocks from the start of the extent to
> +				 * the end of the extent.
>  				 */
> +				if (maxlog == 0)
> +					maxblocks = 0;
> +				else if (maxlog < mp->m_blkbit_log)
> +					maxblocks = 1;
> +				else
> +					maxblocks = 2 << (maxlog - mp->m_blkbit_log);
> +				/*
> +				 * We need to check bbno + i + maxblocks down to
> +				 * bbno + i. We already checked bbno down to
> +				 * bbno + j + 1, so we don't need to check those
> +				 * again.
> +				 */
> +				j = min(i + maxblocks, j);

Makes sense now with a fresher head...
Reviewed-by: Darrick J. Wong <djwong@kernel.org>

What does the xfsprogs version of this patchset look like?

--D

>  				for (; j >= i; j--) {
>  					error = xfs_rtallocate_extent_block(mp,
>  						tp, bbno + j, minlen, maxavail,
> -- 
> 2.41.0
> 

  reply	other threads:[~2023-08-01 23:40 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 [this message]
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=20230801234012.GD11336@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=osandov@osandov.com \
    --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.