From: Sun YangKai <sunk67188@gmail.com>
To: linux-btrfs@vger.kernel.org
Cc: Sun YangKai <sunk67188@gmail.com>
Subject: [PATCH v2 2/7] btrfs: use u8 for reclaim threshold type
Date: Sat, 3 Jan 2026 20:19:49 +0800 [thread overview]
Message-ID: <20260103122504.10924-4-sunk67188@gmail.com> (raw)
In-Reply-To: <20260103122504.10924-2-sunk67188@gmail.com>
The bg_reclaim_threshold field stores a percentage value (0-100), making
u8 a more appropriate type than int. Update the field and related
function return types:
- struct btrfs_space_info::bg_reclaim_threshold
- calc_dynamic_reclaim_threshold()
- btrfs_calc_reclaim_threshold()
The sysfs store function already validates the range is 0-100, ensuring
the cast to u8 is safe.
Signed-off-by: Sun YangKai <sunk67188@gmail.com>
---
fs/btrfs/space-info.c | 6 +++---
fs/btrfs/space-info.h | 14 +++++++-------
fs/btrfs/sysfs.c | 3 ++-
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
index de8bde1081be..29dffbd9aadd 100644
--- a/fs/btrfs/space-info.c
+++ b/fs/btrfs/space-info.c
@@ -2037,7 +2037,7 @@ static u64 calc_unalloc_target(struct btrfs_fs_info *fs_info)
* Typically with 10 block groups as the target, the discrete values this comes
* out to are 0, 10, 20, ... , 80, 90, and 99.
*/
-static int calc_dynamic_reclaim_threshold(const struct btrfs_space_info *space_info)
+static u8 calc_dynamic_reclaim_threshold(const struct btrfs_space_info *space_info)
{
struct btrfs_fs_info *fs_info = space_info->fs_info;
u64 unalloc = atomic64_read(&fs_info->free_chunk_space);
@@ -2052,11 +2052,11 @@ static int calc_dynamic_reclaim_threshold(const struct btrfs_space_info *space_i
if (unused < data_chunk_size)
return 0;
- /* Cast to int is OK because want <= target. */
+ /* Cast to u8 is OK because want <= target. */
return calc_pct_ratio(want, target);
}
-int btrfs_calc_reclaim_threshold(const struct btrfs_space_info *space_info)
+u8 btrfs_calc_reclaim_threshold(const struct btrfs_space_info *space_info)
{
lockdep_assert_held(&space_info->lock);
diff --git a/fs/btrfs/space-info.h b/fs/btrfs/space-info.h
index a49a4c7b0a68..3cf22d7fad20 100644
--- a/fs/btrfs/space-info.h
+++ b/fs/btrfs/space-info.h
@@ -132,15 +132,15 @@ struct btrfs_space_info {
/* Chunk size in bytes */
u64 chunk_size;
+ int clamp; /* Used to scale our threshold for preemptive
+ flushing. The value is >> clamp, so turns
+ out to be a 2^clamp divisor. */
+
/*
* Once a block group drops below this threshold (percents) we'll
* schedule it for reclaim.
*/
- int bg_reclaim_threshold;
-
- int clamp; /* Used to scale our threshold for preemptive
- flushing. The value is >> clamp, so turns
- out to be a 2^clamp divisor. */
+ u8 bg_reclaim_threshold;
bool full; /* indicates that we cannot allocate any more
chunks for this space */
@@ -217,7 +217,7 @@ struct btrfs_space_info {
* freed any space since the last time we made no progress.
*/
bool periodic_reclaim_paused;
- int last_reclaim_threshold;
+ u8 last_reclaim_threshold;
u64 last_reclaim_unused;
};
@@ -298,7 +298,7 @@ void btrfs_dump_space_info_for_trans_abort(struct btrfs_fs_info *fs_info);
void btrfs_init_async_reclaim_work(struct btrfs_fs_info *fs_info);
u64 btrfs_account_ro_block_groups_free_space(struct btrfs_space_info *sinfo);
-int btrfs_calc_reclaim_threshold(const struct btrfs_space_info *space_info);
+u8 btrfs_calc_reclaim_threshold(const struct btrfs_space_info *space_info);
static inline void btrfs_resume_periodic_reclaim(struct btrfs_space_info *space_info)
{
lockdep_assert_held(&space_info->lock);
diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
index f0974f4c0ae4..468c6a9acd3b 100644
--- a/fs/btrfs/sysfs.c
+++ b/fs/btrfs/sysfs.c
@@ -937,7 +937,8 @@ static ssize_t btrfs_sinfo_bg_reclaim_threshold_store(struct kobject *kobj,
if (thresh < 0 || thresh > 100)
return -EINVAL;
- WRITE_ONCE(space_info->bg_reclaim_threshold, thresh);
+ /* Safe to case to u8 after checking thresh's range is between 0 and 100 */
+ WRITE_ONCE(space_info->bg_reclaim_threshold, (u8)thresh);
return len;
}
--
2.51.2
next prev parent reply other threads:[~2026-01-03 13:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-03 12:19 [PATCH v2 0/7] btrfs: fix periodic reclaim condition with some cleanup Sun YangKai
2026-01-03 12:19 ` [PATCH v2 1/7] btrfs: fix periodic reclaim condition Sun YangKai
2026-01-04 19:40 ` Boris Burkov
2026-01-05 13:00 ` Sun Yangkai
2026-01-05 18:21 ` Boris Burkov
2026-01-07 14:09 ` Sun Yangkai
2026-01-07 17:57 ` Boris Burkov
2026-01-08 15:11 ` Sun Yangkai
2026-01-03 12:19 ` Sun YangKai [this message]
2026-01-03 12:19 ` [PATCH v2 3/7] btrfs: clarify reclaim sweep control flow Sun YangKai
2026-01-03 12:19 ` [PATCH v2 4/7] btrfs: change block group reclaim_mark to bool Sun YangKai
2026-01-03 12:19 ` [PATCH v2 5/7] btrfs: reorder btrfs_block_group members to reduce struct size Sun YangKai
2026-01-05 15:07 ` Filipe Manana
2026-01-05 15:26 ` Sun Yangkai
2026-01-03 12:19 ` [PATCH v2 6/7] btrfs: use proper types for btrfs_block_group fields Sun YangKai
2026-01-03 12:19 ` [PATCH v2 7/7] btrfs: consolidate reclaim readiness checks in btrfs_should_reclaim() Sun YangKai
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=20260103122504.10924-4-sunk67188@gmail.com \
--to=sunk67188@gmail.com \
--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