bcache: fixed the issue of low rate at the tail end of dirty data writeback

Started by Zhou Jifeng on Aug 13, 2025 · 2 messages from 2 authors · Last reply Aug 29, 2025

Subsystems (2)

Maintainers (3)

STALE443d

open the first message on its own page

Message details and related content
When c->gc_stats.in_use > BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW, since the
dirty_buckets will not decrease before the GC is triggered, while the
number of dirty sectors waiting for write-back will continuously decrease
, the fps = dirty / dirty_buckets * fp_term gradually approaches 0.
Eventually, when dirty < dirty_buckets, the writeback rate drops to the
lowest level. The larger the cache space is, the higher the dirty value
will be when the write-back speed of dirty data drops to 4k/s. This is
inconsistent with our expectations.

This solution is to set the dirty data write-back speed limit to the
maximum value when c->gc_stats.in_use is high and dirty < dirty_buckets,
so that only a small amount of dirty data can be quickly written back.

Signed-off-by: Zhou Jifeng <redacted>
---
 drivers/md/bcache/writeback.c | 7 +++++++
 1 file changed, 7 insertions(+)
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index 453efbbdc8ee..9fc00fe11201 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -121,6 +121,13 @@ static void __update_writeback_rate(struct cached_dev *dc)
 		}
 		fps = div_s64(dirty, dirty_buckets) * fp_term;
 		if (fragment > 3 && fps > proportional_scaled) {
+			/*
+			 * When there is only a small amount of dirty data, complete the
+			 * write-back operation as quickly as possible.
+			 */
+			if (fps == 0)
+				fps = INT_MAX;
+
 			/* Only overrite the p when fragment > 3 */
 			proportional_scaled = fps;
 		}
-- 
2.18.1
Message details and related content
On Wed, Aug 13, 2025 at 11:23:43AM +0800, Zhou Jifeng wrote:
quoted hunk
When c->gc_stats.in_use > BCH_WRITEBACK_FRAGMENT_THRESHOLD_LOW, since the
dirty_buckets will not decrease before the GC is triggered, while the
number of dirty sectors waiting for write-back will continuously decrease
, the fps = dirty / dirty_buckets * fp_term gradually approaches 0.
Eventually, when dirty < dirty_buckets, the writeback rate drops to the
lowest level. The larger the cache space is, the higher the dirty value
will be when the write-back speed of dirty data drops to 4k/s. This is
inconsistent with our expectations.

This solution is to set the dirty data write-back speed limit to the
maximum value when c->gc_stats.in_use is high and dirty < dirty_buckets,
so that only a small amount of dirty data can be quickly written back.

Signed-off-by: Zhou Jifeng <redacted>
---
 drivers/md/bcache/writeback.c | 7 +++++++
 1 file changed, 7 insertions(+)
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index 453efbbdc8ee..9fc00fe11201 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -121,6 +121,13 @@ static void __update_writeback_rate(struct cached_dev *dc)
 		}
 		fps = div_s64(dirty, dirty_buckets) * fp_term;
 		if (fragment > 3 && fps > proportional_scaled) {
+			/*
+			 * When there is only a small amount of dirty data, complete the
+			 * write-back operation as quickly as possible.
+			 */
+			if (fps == 0)
+				fps = INT_MAX;
+
This will cause int overflow when calculating new_rate.

I agree with your motivation, and this is a bug which should be fixed.
Let me think how to fix it in a more clear and understoodable way.

Thanks.

Coly Li

 			/* Only overrite the p when fragment > 3 */
 			proportional_scaled = fps;
 		}
-- 
2.18.1
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help