Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Sun YangKai <sunk67188@gmail.com>
To: Boris Burkov <boris@bur.io>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: change block group reclaim_mark to bool
Date: Wed, 24 Jun 2026 14:18:05 +0800	[thread overview]
Message-ID: <26f7b745-6a8d-4fcd-9393-70b2345f24ca@gmail.com> (raw)
In-Reply-To: <20260624041909.GA2011094@zen.localdomain>



On 2026/6/24 12:19, Boris Burkov wrote:
> On Wed, Jun 24, 2026 at 12:02:27PM +0800, Sun YangKai wrote:
>> The reclaim_mark field in struct btrfs_block_group was a u64 that was
>> incremented when marking block groups for reclaim during sweeping, but
>> the actual counter value was never used - only the zero/non-zero state
>> mattered for determining if a block group needed reclaim.
>>
>> Convert it to a bool to properly reflect its usage and reduce memory
>> footprint by 8 bytes. Update assignments to use true/false instead of
>> increment and zero.
>>
> 
> LGTM, thanks.
> Reviewed-by: Boris Burkov <boris@bur.io>
> 
>> Signed-off-by: Sun YangKai <sunk67188@gmail.com>
>> ---
>>   fs/btrfs/block-group.c | 2 +-
>>   fs/btrfs/block-group.h | 7 ++++++-
>>   fs/btrfs/space-info.c  | 2 +-
>>   3 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
>> index 9e937407d12a9..5829c806c4d48 100644
>> --- a/fs/btrfs/block-group.c
>> +++ b/fs/btrfs/block-group.c
>> @@ -3923,7 +3923,7 @@ int btrfs_update_block_group(struct btrfs_trans_handle *trans,
>>   		old_val += num_bytes;
>>   		cache->used = old_val;
>>   		cache->reserved -= num_bytes;
>> -		cache->reclaim_mark = 0;
>> +		cache->reclaim_mark = false;
>>   		space_info->bytes_reserved -= num_bytes;
>>   		space_info->bytes_used += num_bytes;
>>   		space_info->disk_used += num_bytes * factor;
>> diff --git a/fs/btrfs/block-group.h b/fs/btrfs/block-group.h
>> index 790c2d467af57..942befdf75df7 100644
>> --- a/fs/btrfs/block-group.h
>> +++ b/fs/btrfs/block-group.h
>> @@ -263,6 +263,12 @@ struct btrfs_block_group {
>>   
>>   	enum btrfs_block_group_size_class size_class:8;
>>   
>> +	/*
>> +	 * Mark this blockgroup is not used for allocation
>> +	 * between two reclaim sweeps.
> 
> nit: this grammar doesn't parse great to me. Maybe drop "Mark"?
> or change it to "We identified this for reclaim on a previous pass, so
> it stably needs reclaim across passes" or something like that.

I also think this comment should be polished but have no idea. Your nit 
helps a lot. How about this:

Tracks whether this blockgroup has been idle during the previous 
periodic sweep cycle. It is set to false on allocation, and set to true 
by the periodic sweep upon first pass. If found true on a subsequent 
scan, the blockgroup is eligible for reclamation.

>> +	 */
>> +	bool reclaim_mark;
>> +
>>   	/*
>>   	 * Number of extents in this block group used for swap files.
>>   	 * All accesses protected by the spinlock 'lock'.
>> @@ -281,7 +287,6 @@ struct btrfs_block_group {
>>   	struct list_head active_bg_list;
>>   	struct work_struct zone_finish_work;
>>   	struct extent_buffer *last_eb;
>> -	u64 reclaim_mark;
>>   };
>>   
>>   static inline u64 btrfs_block_group_end(const struct btrfs_block_group *block_group)
>> diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
>> index e6641597b321e..39a28e1bec8ad 100644
>> --- a/fs/btrfs/space-info.c
>> +++ b/fs/btrfs/space-info.c
>> @@ -2156,7 +2156,7 @@ static bool do_reclaim_sweep(struct btrfs_space_info *space_info, int raid)
>>   			will_reclaim = true;
>>   			reclaim = true;
>>   		}
>> -		bg->reclaim_mark++;
>> +		bg->reclaim_mark = true;
>>   		spin_unlock(&bg->lock);
>>   		if (reclaim)
>>   			btrfs_mark_bg_to_reclaim(bg);
>> -- 
>> 2.54.0
>>


      reply	other threads:[~2026-06-24  6:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24  4:02 [PATCH] btrfs: change block group reclaim_mark to bool Sun YangKai
2026-06-24  4:19 ` Boris Burkov
2026-06-24  6:18   ` Sun YangKai [this message]

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=26f7b745-6a8d-4fcd-9393-70b2345f24ca@gmail.com \
    --to=sunk67188@gmail.com \
    --cc=boris@bur.io \
    --cc=linux-btrfs@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