linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>,
	Ritesh Harjani <riteshh@linux.ibm.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jan Kara <jack@suse.cz>, Ritesh Harjani <ritesh.list@gmail.com>
Subject: Re: [RFC 07/11] ext4: Avoid scanning smaller extents in BG during CR1
Date: Thu, 9 Mar 2023 13:20:52 +0100	[thread overview]
Message-ID: <20230309122052.73k3tye5ev72elkt@quack3> (raw)
In-Reply-To: <6fefb97af05081d344185334a36e90f093ccf310.1674822311.git.ojaswin@linux.ibm.com>

On Fri 27-01-23 18:07:34, Ojaswin Mujoo wrote:
> When we are inside ext4_mb_complex_scan_group() in CR1, we can be sure
> that this group has atleast 1 big enough continuous free extent to satisfy
> our request because (free / fragments) > goal length.
> 
> Hence, instead of wasting time looping over smaller free extents, only
> try to consider the free extent if we are sure that it has enough
> continuous free space to satisfy goal length. This is particularly
> useful when scanning highly fragmented BGs in CR1 as, without this
> patch, the allocator might stop scanning early before reaching the big
> enough free extent (due to ac_found > mb_max_to_scan) which causes us to
> uncessarily trim the request.
> 
> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>

Looks good to me. Feel free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ext4/mballoc.c | 19 ++++++++++++++++++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index c4ab8f412d32..14529d2fe65f 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -2279,7 +2279,7 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
>  	struct super_block *sb = ac->ac_sb;
>  	void *bitmap = e4b->bd_bitmap;
>  	struct ext4_free_extent ex;
> -	int i;
> +	int i, j, freelen;
>  	int free;
>  
>  	free = e4b->bd_info->bb_free;
> @@ -2306,6 +2306,23 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
>  			break;
>  		}
>  
> +		if (ac->ac_criteria < CR2) {
> +			/*
> +			 * In CR1, we are sure that this group will
> +			 * have a large enough continuous free extent, so skip
> +			 * over the smaller free extents
> +			 */
> +			j = mb_find_next_bit(bitmap,
> +						EXT4_CLUSTERS_PER_GROUP(sb), i);
> +			freelen = j - i;
> +
> +			if (freelen < ac->ac_g_ex.fe_len) {
> +				i = j;
> +				free -= freelen;
> +				continue;
> +			}
> +		}
> +
>  		mb_find_extent(e4b, i, ac->ac_g_ex.fe_len, &ex);
>  		if (WARN_ON(ex.fe_len <= 0))
>  			break;
> -- 
> 2.31.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2023-03-09 12:21 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 12:37 [RFC 00/11] multiblock allocator improvements Ojaswin Mujoo
2023-01-27 12:37 ` [RFC 01/11] ext4: mballoc: Remove useless setting of ac_criteria Ojaswin Mujoo
2023-03-09 11:36   ` Jan Kara
2023-01-27 12:37 ` [RFC 02/11] ext4: Remove unused extern variables declaration Ojaswin Mujoo
2023-03-09 11:37   ` Jan Kara
2023-01-27 12:37 ` [RFC 03/11] ext4: mballoc: Fix getting the right group desc in ext4_mb_prefetch_fini Ojaswin Mujoo
2023-03-09 11:42   ` Jan Kara
2023-01-27 12:37 ` [RFC 04/11] ext4: Convert mballoc cr (criteria) to enum Ojaswin Mujoo
2023-03-09 12:11   ` Jan Kara
2023-03-17 10:26     ` Ojaswin Mujoo
2023-03-23 10:55       ` Jan Kara
2023-03-25 14:42         ` Ojaswin Mujoo
2023-04-20  6:32           ` Ojaswin Mujoo
2023-04-20 14:58             ` Jan Kara
2023-01-27 12:37 ` [RFC 05/11] ext4: Add per CR extent scanned counter Ojaswin Mujoo
2023-03-09 12:14   ` Jan Kara
2023-01-27 12:37 ` [RFC 06/11] ext4: Add counter to track successful allocation of goal length Ojaswin Mujoo
2023-03-09 12:17   ` Jan Kara
2023-01-27 12:37 ` [RFC 07/11] ext4: Avoid scanning smaller extents in BG during CR1 Ojaswin Mujoo
2023-03-09 12:20   ` Jan Kara [this message]
2023-01-27 12:37 ` [RFC 08/11] ext4: Don't skip prefetching BLOCK_UNINIT groups Ojaswin Mujoo
2023-03-09 14:14   ` Jan Kara
2023-03-17 10:55     ` Ojaswin Mujoo
2023-03-23 10:57       ` Jan Kara
2023-03-25 14:43         ` Ojaswin Mujoo
2023-03-26  3:54       ` Theodore Ts'o
2023-01-27 12:37 ` [RFC 09/11] ext4: Ensure ext4_mb_prefetch_fini() is called for all prefetched BGs Ojaswin Mujoo
2023-03-09 14:23   ` Jan Kara
2023-01-27 12:37 ` [RFC 10/11] ext4: Abstract out logic to search average fragment list Ojaswin Mujoo
2023-03-09 14:25   ` Jan Kara
2023-01-27 12:37 ` [RFC 11/11] ext4: Add allocation criteria 1.5 (CR1_5) Ojaswin Mujoo
2023-03-09 15:06   ` Jan Kara
2023-03-17 11:37     ` Ojaswin Mujoo
2023-03-23 11:05       ` Jan Kara
2023-03-25 14:46         ` Ojaswin Mujoo

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=20230309122052.73k3tye5ev72elkt@quack3 \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=riteshh@linux.ibm.com \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).