All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Fengnan Chang <changfengnan@bytedance.com>
Cc: adilger.kernel@dilger.ca, guoqing.jiang@linux.dev,
	linux-ext4@vger.kernel.org,
	kernel test robot <oliver.sang@intel.com>
Subject: Re: [PATCH v3] ext4: improve trim efficiency
Date: Thu, 17 Aug 2023 23:43:30 -0400	[thread overview]
Message-ID: <20230818034330.GE3464136@mit.edu> (raw)
In-Reply-To: <20230725121848.26865-1-changfengnan@bytedance.com>

On Tue, Jul 25, 2023 at 08:18:48PM +0800, Fengnan Chang wrote:
> In commit a015434480dc("ext4: send parallel discards on commit
> completions"), issue all discard commands in parallel make all
> bios could merged into one request, so lowlevel drive can issue
> multi segments in one time which is more efficiency, but commit
> 55cdd0af2bc5 ("ext4: get discard out of jbd2 commit kthread contex")
> seems broke this way, let's fix it.

Thanks for the patch.  A few things that I'd like to see changed.

> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index a2475b8c9fb5..b75ca1df0d30 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -6790,7 +6790,8 @@ int ext4_group_add_blocks(handle_t *handle, struct super_block *sb,
>   * be called with under the group lock.
>   */
>  static int ext4_trim_extent(struct super_block *sb,
> -		int start, int count, struct ext4_buddy *e4b)
> +		int start, int count, bool noalloc, struct ext4_buddy *e4b,
> +		struct bio **biop, struct ext4_free_data **entryp)

The function ext4_trim_extent() is used in one place, by
ext4_try_to_trim_range().  So instead of adding the new parameters
noalloc and extryp...

> @@ -6812,9 +6813,16 @@ __acquires(bitlock)
>  	 */
>  	mb_mark_used(e4b, &ex);
>  	ext4_unlock_group(sb, group);
> -	ret = ext4_issue_discard(sb, group, start, count, NULL);
> +	ret = ext4_issue_discard(sb, group, start, count, biop);
> +	if (!ret && !noalloc) {
> +		struct ext4_free_data *entry = kmem_cache_alloc(ext4_free_data_cachep,
> +				GFP_NOFS|__GFP_NOFAIL);
> +		entry->efd_start_cluster = start;
> +		entry->efd_count = count;
> +		*entryp  = entry;
> +	}
> +

... I think it might be better to move the allocation and
initialization the ext4_free_data structure to ext4_trim_extent()'s
caller.

In the current patch, we are adding the entry to the linked list, and
we actually *use* the linked list in ext4_try_to_trim_range().  By
move the code which allocates the entry to the same place, we
eliminate some extra variables added to the ext4_trim_extent()
function, and it makes the code easier to read.

In fact, given that ext4_trim_extent() is used only once by its
caller, we could just inline the code (which isn't actually all that
much) into ext4_Try_to_trim_range().  That would eliminate the need
for the __acquires(bitlock) and __release(bitlock) sparse annotations,
as well as the "assert_spin_locked()".

That also keeps the mb_mark_used() and mb_free_blocks() calls in the
same function, which again improves code readability.

Thanks,

						- Ted

  parent reply	other threads:[~2023-08-18  3:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-25 12:18 [PATCH v3] ext4: improve trim efficiency Fengnan Chang
2023-07-31  2:26 ` Guoqing Jiang
2023-07-31 12:52   ` [External] " Fengnan Chang
2023-08-09  8:20     ` Fengnan Chang
2023-08-18  3:43 ` Theodore Ts'o [this message]
2023-08-18  7:14   ` Fengnan Chang
2023-08-18 16:55     ` Theodore Ts'o

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=20230818034330.GE3464136@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=changfengnan@bytedance.com \
    --cc=guoqing.jiang@linux.dev \
    --cc=linux-ext4@vger.kernel.org \
    --cc=oliver.sang@intel.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.