Re: [PATCH 4/4] xfs: speed up write operations by using non-overlapped lookups when possible

[Dave Chinner <david@fromorbit.com>]

On Thu, Apr 14, 2022 at 03:54:22PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Reverse mapping on a reflink-capable filesystem has some pretty high
> overhead when performing file operations.  This is because the rmap
> records for logically and physically adjacent extents might not be
> adjacent in the rmap index due to data block sharing.  As a result, we
> use expensive overlapped-interval btree search, which walks every record
> that overlaps with the supplied key in the hopes of finding the record.
> 
> However, profiling data shows that when the index contains a record that
> is an exact match for a query key, the non-overlapped btree search
> function can find the record much faster than the overlapped version.
> Try the non-overlapped lookup first when we're trying to find the left
> neighbor rmap record for a given file mapping, which makes unwritten
> extent conversion and remap operations run faster if data block sharing
> is minimal in this part of the filesystem.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> ---
>  fs/xfs/libxfs/xfs_rmap.c |   35 ++++++++++++++++++++++++++++++-----
>  fs/xfs/libxfs/xfs_rmap.h |    3 ---
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> 
> diff --git a/fs/xfs/libxfs/xfs_rmap.c b/fs/xfs/libxfs/xfs_rmap.c
> index 5aa94deb3afd..bd394138df9e 100644
> --- a/fs/xfs/libxfs/xfs_rmap.c
> +++ b/fs/xfs/libxfs/xfs_rmap.c
> @@ -299,7 +299,7 @@ xfs_rmap_find_left_neighbor_helper(
>   * return a match with the same owner and adjacent physical and logical
>   * block ranges.
>   */
> -int
> +STATIC int
>  xfs_rmap_find_left_neighbor(
>  	struct xfs_btree_cur	*cur,
>  	xfs_agblock_t		bno,
> @@ -332,10 +332,35 @@ xfs_rmap_find_left_neighbor(
>  	trace_xfs_rmap_find_left_neighbor_query(cur->bc_mp,
>  			cur->bc_ag.pag->pag_agno, bno, 0, owner, offset, flags);
>  
> -	error = xfs_rmap_query_range(cur, &info.high, &info.high,
> -			xfs_rmap_find_left_neighbor_helper, &info);
> -	if (error == -ECANCELED)
> -		error = 0;
> +	/*
> +	 * Historically, we always used the range query to walk every reverse
> +	 * mapping that could possibly overlap the key that the caller asked
> +	 * for, and filter out the ones that don't.  That is very slow when
> +	 * there are a lot of records.
> +	 *
> +	 * However, there are two scenarios where the classic btree search can
> +	 * produce correct results -- if the index contains a record that is an
> +	 * exact match for the lookup key; and if there are no other records
> +	 * between the record we want and the key we supplied.
> +	 *
> +	 * As an optimization, try a non-overlapped lookup first.  This makes
> +	 * extent conversion and remap operations run a bit faster if the
> +	 * physical extents aren't being shared.  If we don't find what we
> +	 * want, we fall back to the overlapped query.
> +	 */
> +	error = xfs_rmap_lookup_le(cur, bno, owner, offset, flags, irec, stat);
> +	if (error)
> +		return error;
> +	if (*stat) {
> +		*stat = 0;
> +		xfs_rmap_find_left_neighbor_helper(cur, irec, &info);
> +	}
> +	if (!(*stat)) {
> +		error = xfs_rmap_query_range(cur, &info.high, &info.high,
> +				xfs_rmap_find_left_neighbor_helper, &info);
> +		if (error == -ECANCELED)
> +			error = 0;
> +	}

Same comment as previous patch.

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com