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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <dwxgw72rv3tehln3yj3f66wg3gl664obbxkvmirh7l5bbw4sgq@62mtjzuxftdi>
Date: Fri, 29 Aug 2025 10:51:52 +0800
From: Coly Li <colyli@...nel.org>
To: Zhou Jifeng <zhoujifeng@...inos.com.cn>
Cc: linux-bcache@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bcache: fixed the issue of low rate at the tail end of
 dirty data writeback

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@...inos.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
> 
>