From: Mingzhe Zou <mingzhe.zou@easystack.cn>
To: colyli@suse.de, linux-bcache@vger.kernel.org
Cc: bcache@lists.ewheeler.net, zoumingzhe@qq.com
Subject: [PATCH v4 1/2] bcache: Separate bch_moving_gc() from bch_btree_gc()
Date: Mon, 10 Jul 2023 15:07:00 +0800 [thread overview]
Message-ID: <20230710070702.68-1-mingzhe.zou@easystack.cn> (raw)
From: Mingzhe Zou <zoumingzhe@qq.com>
Moving gc uses cache->heap to defragment disk. Unlike btree gc,
moving gc only takes up part of the disk bandwidth.
The number of heap is constant. However, the buckets released by
each moving gc is limited. So bch_moving_gc() needs to be called
multiple times.
If bch_gc_thread() always calls bch_btree_gc(), it will block
the IO request.This patch allows bch_gc_thread() to only call
bch_moving_gc() when there are many fragments.
Signed-off-by: Mingzhe Zou <mingzhe.zou@easystack.cn>
---
drivers/md/bcache/bcache.h | 4 +-
drivers/md/bcache/btree.c | 73 ++++++++++++++++++++++++++++++++++--
drivers/md/bcache/movinggc.c | 7 +++-
drivers/md/bcache/super.c | 2 +
4 files changed, 81 insertions(+), 5 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index 5a79bb3c272f..155deff0ce05 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -461,7 +461,8 @@ struct cache {
* until a gc finishes - otherwise we could pointlessly burn a ton of
* cpu
*/
- unsigned int invalidate_needs_gc;
+ unsigned int invalidate_needs_gc:1;
+ unsigned int only_moving_gc:1;
bool discard; /* Get rid of? */
@@ -629,6 +630,7 @@ struct cache_set {
struct gc_stat gc_stats;
size_t nbuckets;
size_t avail_nbuckets;
+ size_t fragment_nbuckets;
struct task_struct *gc_thread;
/* Where in the btree gc currently is */
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index fd121a61f17c..475ae69b1916 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -88,6 +88,7 @@
* Test module load/unload
*/
+#define COPY_GC_PERCENT 5
#define MAX_NEED_GC 64
#define MAX_SAVE_PRIO 72
#define MAX_GC_TIMES 100
@@ -1726,6 +1727,7 @@ static void btree_gc_start(struct cache_set *c)
mutex_lock(&c->bucket_lock);
+ set_gc_sectors(c);
c->gc_mark_valid = 0;
c->gc_done = ZERO_KEY;
@@ -1846,8 +1848,58 @@ static void bch_btree_gc(struct cache_set *c)
memcpy(&c->gc_stats, &stats, sizeof(struct gc_stat));
trace_bcache_gc_end(c);
+}
+
+extern unsigned int bch_cutoff_writeback;
+extern unsigned int bch_cutoff_writeback_sync;
+
+static bool moving_gc_should_run(struct cache_set *c)
+{
+ struct bucket *b;
+ struct cache *ca = c->cache;
+ size_t moving_gc_threshold = ca->sb.bucket_size >> 2, frag_percent;
+ unsigned long used_buckets = 0, frag_buckets = 0, move_buckets = 0;
+ unsigned long dirty_sectors = 0, frag_sectors = 0, used_sectors = 0;
+
+ mutex_lock(&c->bucket_lock);
+ for_each_bucket(b, ca) {
+ if (GC_MOVE(b) || GC_MARK(b) != GC_MARK_DIRTY)
+ continue;
+
+ used_buckets++;
+
+ used_sectors = GC_SECTORS_USED(b);
+ dirty_sectors += used_sectors;
+
+ if (used_sectors < ca->sb.bucket_size)
+ frag_buckets++;
+
+ if (used_sectors <= moving_gc_threshold)
+ move_buckets++;
+ }
+ mutex_unlock(&c->bucket_lock);
+
+ c->fragment_nbuckets = frag_buckets;
- bch_moving_gc(c);
+ if (used_buckets < c->nbuckets * bch_cutoff_writeback / 100)
+ return false;
+
+ if (move_buckets > ca->heap.size)
+ return true;
+
+ frag_sectors = used_buckets * ca->sb.bucket_size - dirty_sectors;
+ frag_percent = div_u64(frag_sectors * 100, ca->sb.bucket_size * c->nbuckets);
+
+ if (frag_percent >= COPY_GC_PERCENT)
+ return true;
+
+ if (used_buckets > c->nbuckets * bch_cutoff_writeback_sync / 100)
+ return true;
+
+ if (c->gc_stats.in_use > bch_cutoff_writeback_sync && frag_buckets > 0)
+ return true;
+
+ return false;
}
static bool gc_should_run(struct cache_set *c)
@@ -1860,6 +1912,19 @@ static bool gc_should_run(struct cache_set *c)
if (atomic_read(&c->sectors_to_gc) < 0)
return true;
+ /*
+ * Moving gc uses cache->heap to defragment disk. Unlike btree gc,
+ * moving gc only takes up part of the disk bandwidth.
+ * The number of heap is constant. However, the buckets released by
+ * each moving gc is limited. So bch_moving_gc() needs to be called
+ * multiple times. If bch_gc_thread() always calls bch_btree_gc(),
+ * it will block the IO request.
+ */
+ if (c->copy_gc_enabled && moving_gc_should_run(c)) {
+ ca->only_moving_gc = 1;
+ return true;
+ }
+
return false;
}
@@ -1877,8 +1942,10 @@ static int bch_gc_thread(void *arg)
test_bit(CACHE_SET_IO_DISABLE, &c->flags))
break;
- set_gc_sectors(c);
- bch_btree_gc(c);
+ if (!c->cache->only_moving_gc)
+ bch_btree_gc(c);
+
+ bch_moving_gc(c);
}
wait_for_kthread_stop();
diff --git a/drivers/md/bcache/movinggc.c b/drivers/md/bcache/movinggc.c
index 9f32901fdad1..93a449226f36 100644
--- a/drivers/md/bcache/movinggc.c
+++ b/drivers/md/bcache/movinggc.c
@@ -200,6 +200,8 @@ void bch_moving_gc(struct cache_set *c)
struct bucket *b;
unsigned long sectors_to_move, reserve_sectors;
+ c->cache->only_moving_gc = 0;
+
if (!c->copy_gc_enabled)
return;
@@ -212,7 +214,7 @@ void bch_moving_gc(struct cache_set *c)
ca->heap.used = 0;
for_each_bucket(b, ca) {
- if (GC_MARK(b) == GC_MARK_METADATA ||
+ if (GC_MOVE(b) || GC_MARK(b) == GC_MARK_METADATA ||
!GC_SECTORS_USED(b) ||
GC_SECTORS_USED(b) == ca->sb.bucket_size ||
atomic_read(&b->pin))
@@ -235,6 +237,9 @@ void bch_moving_gc(struct cache_set *c)
sectors_to_move -= GC_SECTORS_USED(b);
}
+ pr_info("moving gc: on set %pU, %lu sectors from %zu buckets",
+ c->sb.set_uuid, sectors_to_move, ca->heap.used);
+
while (heap_pop(&ca->heap, b, bucket_cmp))
SET_GC_MOVE(b, 1);
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 0ae2b3676293..7e556bc0ec04 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -2112,6 +2112,8 @@ static int run_cache_set(struct cache_set *c)
if (bch_gc_thread_start(c))
goto err;
+ force_wake_up_gc(c);
+
closure_sync(&cl);
c->cache->sb.last_mount = (u32)ktime_get_real_seconds();
bcache_write_super(c);
--
2.17.1.windows.2
next reply other threads:[~2023-07-10 7:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 7:07 Mingzhe Zou [this message]
2023-07-10 7:07 ` [PATCH v4 2/2] bcache: only copy dirty data during moving gc Mingzhe Zou
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=20230710070702.68-1-mingzhe.zou@easystack.cn \
--to=mingzhe.zou@easystack.cn \
--cc=bcache@lists.ewheeler.net \
--cc=colyli@suse.de \
--cc=linux-bcache@vger.kernel.org \
--cc=zoumingzhe@qq.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).