On Wed 23-10-24 18:00:32, Jim Zhao wrote:
> With the strictlimit flag, wb_thresh acts as a hard limit in
> balance_dirty_pages() and wb_position_ratio(). When device write
> operations are inactive, wb_thresh can drop to 0, causing writes to
> be blocked. The issue occasionally occurs in fuse fs, particularly
> with network backends, the write thread is blocked frequently during
> a period. To address it, this patch raises the minimum wb_thresh to a
> controllable level, similar to the non-strictlimit case.
>
> Signed-off-by: Jim Zhao <jimzhao.ai@xxxxxxxxx>
...
> + /*
> + * With strictlimit flag, the wb_thresh is treated as
> + * a hard limit in balance_dirty_pages() and wb_position_ratio().
> + * It's possible that wb_thresh is close to zero, not because
> + * the device is slow, but because it has been inactive.
> + * To prevent occasional writes from being blocked, we raise wb_thresh.
> + */
> + if (unlikely(wb->bdi->capabilities & BDI_CAP_STRICTLIMIT)) {
> + unsigned long limit = hard_dirty_limit(dom, dtc->thresh);
> + u64 wb_scale_thresh = 0;
> +
> + if (limit > dtc->dirty)
> + wb_scale_thresh = (limit - dtc->dirty) / 100;
> + wb_thresh = max(wb_thresh, min(wb_scale_thresh, wb_max_thresh / 4));
> + }
What you propose makes sense in principle although I'd say this is mostly a
userspace setup issue - with strictlimit enabled, you're kind of expected
to set min_ratio exactly if you want to avoid these startup issues. But I
tend to agree that we can provide a bit of a slack for a bdi without
min_ratio configured to ramp up.
But I'd rather pick the logic like:
/*
* If bdi does not have min_ratio configured and it was inactive,
* bump its min_ratio to 0.1% to provide it some room to ramp up.
*/
if (!wb_min_ratio && !numerator)
wb_min_ratio = min(BDI_RATIO_SCALE / 10, wb_max_ratio / 2);
That would seem like a bit more systematic way than the formula you propose
above...
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
