public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 18/19] xfs: simplify and optimize the RT allocation fallback cascade
Date: Thu, 14 Dec 2023 13:32:21 -0800	[thread overview]
Message-ID: <20231214213221.GH361584@frogsfrogsfrogs> (raw)
In-Reply-To: <20231214063438.290538-19-hch@lst.de>

On Thu, Dec 14, 2023 at 07:34:37AM +0100, Christoph Hellwig wrote:
> There are currently multiple levels of fall back if an RT allocation
> can not be satisfied:
> 
>  1) xfs_rtallocate_extent extents the minlen and reduces the maxlen due

                            ^^^^^^^ extends?

>     to the extent size hint.  If that can't be done, it return -ENOSPC
>     and let's xfs_bmap_rtalloc retry, which then not only drops the
>     extent size hint based alignment, but also the minlen adjustment
>  2) if xfs_rtallocate_extent gets -ENOSPC from the underlying functions,
>     it only drops the extent size hint based alignment and retries
>  3) if that still does not succeed, xfs_rtallocate_extent drops the
>     extent size hint (which is a complex no-op at this point) and the
>     minlen using the same code as (1) above
>  4) if that still doesn't success and the caller wanted an allocation
>     near a blkno, drop that blkno hint.
> 
> The handling in 1 is rather inefficient as we could just drop the
> alignment and continue, and 2/3 interact in really weird ways due to
> the duplicate policy.
> 
> Move aligning the min and maxlen out of xfs_rtallocate_extent and into
> a helper called directly by xfs_bmap_rtalloc.  This allows just
> continuing with the allocation if we have to drop the alignment instead
> of going through the retry loop and also dropping the perfectly the
> minlen adjustment that didn't cause the problem, and then just use

"...dropping the perfectly *usable* minlen adjustment..." ?

> a single retry that drops both the minlen and alignment requirement
> when we really are out of space, thus consolidating cases (2) and (3)
> above.

How can we drop the minlen requirement, won't that result in undersize
mapping allocations?  Or is the subtlety here that for realtime files,
that's ok because we never have forced multi-rtx allocations like we do
for the data device?

--D

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_rtalloc.c | 58 ++++++++++++++++++++++++++------------------
>  1 file changed, 35 insertions(+), 23 deletions(-)
> 
> diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
> index 595740d18dc4c3..16255617629ef5 100644
> --- a/fs/xfs/xfs_rtalloc.c
> +++ b/fs/xfs/xfs_rtalloc.c
> @@ -1088,21 +1088,6 @@ xfs_rtallocate_extent(
>  	ASSERT(xfs_isilocked(args.mp->m_rbmip, XFS_ILOCK_EXCL));
>  	ASSERT(minlen > 0 && minlen <= maxlen);
>  
> -	/*
> -	 * If prod is set then figure out what to do to minlen and maxlen.
> -	 */
> -	if (prod > 1) {
> -		xfs_rtxlen_t	i;
> -
> -		if ((i = maxlen % prod))
> -			maxlen -= i;
> -		if ((i = minlen % prod))
> -			minlen += prod - i;
> -		if (maxlen < minlen)
> -			return -ENOSPC;
> -	}
> -
> -retry:
>  	if (start == 0) {
>  		error = xfs_rtallocate_extent_size(&args, minlen,
>  				maxlen, len, prod, rtx);
> @@ -1111,13 +1096,8 @@ xfs_rtallocate_extent(
>  				maxlen, len, prod, rtx);
>  	}
>  	xfs_rtbuf_cache_relse(&args);
> -	if (error) {
> -		if (error == -ENOSPC && prod > 1) {
> -			prod = 1;
> -			goto retry;
> -		}
> +	if (error)
>  		return error;
> -	}
>  
>  	/*
>  	 * If it worked, update the superblock.
> @@ -1348,6 +1328,35 @@ xfs_rtpick_extent(
>  	return 0;
>  }
>  
> +static void
> +xfs_rtalloc_align_minmax(
> +	xfs_rtxlen_t		*raminlen,
> +	xfs_rtxlen_t		*ramaxlen,
> +	xfs_rtxlen_t		*prod)
> +{
> +	xfs_rtxlen_t		newmaxlen = *ramaxlen;
> +	xfs_rtxlen_t		newminlen = *raminlen;
> +	xfs_rtxlen_t		slack;
> +
> +	slack = newmaxlen % *prod;
> +	if (slack)
> +		newmaxlen -= slack;
> +	slack = newminlen % *prod;
> +	if (slack)
> +		newminlen += *prod - slack;
> +
> +	/*
> +	 * If adjusting for extent size hint alignment produces an invalid
> +	 * min/max len combination, go ahead without it.
> +	 */
> +	if (newmaxlen < newminlen) {
> +		*prod = 1;
> +		return;
> +	}
> +	*ramaxlen = newmaxlen;
> +	*raminlen = newminlen;
> +}
> +
>  int
>  xfs_bmap_rtalloc(
>  	struct xfs_bmalloca	*ap)
> @@ -1430,10 +1439,13 @@ xfs_bmap_rtalloc(
>  	 * perfectly aligned, otherwise it will just get us in trouble.
>  	 */
>  	div_u64_rem(ap->offset, align, &mod);
> -	if (mod || ap->length % align)
> +	if (mod || ap->length % align) {
>  		prod = 1;
> -	else
> +	} else {
>  		prod = xfs_extlen_to_rtxlen(mp, align);
> +		if (prod > 1)
> +			xfs_rtalloc_align_minmax(&raminlen, &ralen, &prod);
> +	}
>  
>  	error = xfs_rtallocate_extent(ap->tp, start, raminlen, ralen, &ralen,
>  			ap->wasdel, prod, &rtx);
> -- 
> 2.39.2
> 
> 

  reply	other threads:[~2023-12-14 21:32 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14  6:34 RT allocator tidy ups Christoph Hellwig
2023-12-14  6:34 ` [PATCH 01/19] xfs: consider minlen sized extents in xfs_rtallocate_extent_block Christoph Hellwig
2023-12-14 21:02   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 02/19] xfs: turn the xfs_trans_mod_dquot_byino stub into an inline function Christoph Hellwig
2023-12-14 20:44   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 03/19] xfs: remove the xfs_alloc_arg argument to xfs_bmap_btalloc_accounting Christoph Hellwig
2023-12-14 20:46   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 04/19] xfs: also use xfs_bmap_btalloc_accounting for RT allocations Christoph Hellwig
2023-12-14 20:46   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 05/19] xfs: move xfs_bmap_rtalloc to xfs_rtalloc.c Christoph Hellwig
2023-12-14 20:48   ` Darrick J. Wong
2023-12-15  4:09     ` Christoph Hellwig
2023-12-15  6:35       ` Christoph Hellwig
2023-12-14  6:34 ` [PATCH 06/19] xfs: return -ENOSPC from xfs_rtallocate_* Christoph Hellwig
2023-12-14 20:50   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 07/19] xfs: reflow the tail end of xfs_bmap_rtalloc Christoph Hellwig
2023-12-14 20:51   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 08/19] xfs: indicate if xfs_bmap_adjacent changed ap->blkno Christoph Hellwig
2023-12-14 20:52   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 09/19] xfs: cleanup picking the start extent hint in xfs_bmap_rtalloc Christoph Hellwig
2023-12-14 20:59   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 10/19] xfs: move xfs_rtget_summary to xfs_rtbitmap.c Christoph Hellwig
2023-12-14 21:00   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 11/19] xfs: split xfs_rtmodify_summary_int Christoph Hellwig
2023-12-14 21:02   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 12/19] xfs: tidy up xfs_rtallocate_extent_block Christoph Hellwig
2023-12-14 21:16   ` Darrick J. Wong
2023-12-15  4:10     ` Christoph Hellwig
2023-12-14  6:34 ` [PATCH 13/19] xfs: tidy up xfs_rtallocate_extent_exact Christoph Hellwig
2023-12-14 21:17   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 14/19] xfs: factor out a xfs_rtalloc_sumlevel helper Christoph Hellwig
2023-12-14 21:05   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 15/19] xfs: remove rt-wrappers from xfs_format.h Christoph Hellwig
2023-12-14 21:18   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 16/19] xfs: remove XFS_RTMIN/XFS_RTMAX Christoph Hellwig
2023-12-14 21:21   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 17/19] xfs: reorder the minlen and prod calculations in xfs_bmap_rtalloc Christoph Hellwig
2023-12-14 21:24   ` Darrick J. Wong
2023-12-14  6:34 ` [PATCH 18/19] xfs: simplify and optimize the RT allocation fallback cascade Christoph Hellwig
2023-12-14 21:32   ` Darrick J. Wong [this message]
2023-12-15  4:12     ` Christoph Hellwig
2023-12-14  6:34 ` [PATCH 19/19] xfs: fold xfs_rtallocate_extent into xfs_bmap_rtalloc Christoph Hellwig
2023-12-14 21:35   ` Darrick J. Wong

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=20231214213221.GH361584@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=chandan.babu@oracle.com \
    --cc=hch@lst.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox