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

Zhou Jifeng posted 1 patch 1 month, 3 weeks ago
drivers/md/bcache/writeback.c | 7 +++++++
1 file changed, 7 insertions(+)
[PATCH] bcache: fixed the issue of low rate at the tail end of dirty data writeback
Posted by Zhou Jifeng 1 month, 3 weeks ago
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 <zhoujifeng@kylinos.com.cn>
---
 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
Re: [PATCH] bcache: fixed the issue of low rate at the tail end of dirty data writeback
Posted by Coly Li 1 month ago
On Wed, Aug 13, 2025 at 11:23:43AM +0800, Zhou Jifeng wrote:
> 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 <zhoujifeng@kylinos.com.cn>
> ---
>  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
> 
>