From: Jim Zhao <jimzhao.ai@gmail.com>
To: akpm@linux-foundation.org
Cc: jimzhao.ai@gmail.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
willy@infradead.org
Subject: Re: [PATCH] mm/page-writeback: Raise wb_thresh to prevent write blocking with strictlimit
Date: Thu, 24 Oct 2024 14:09:54 +0800 [thread overview]
Message-ID: <20241024060954.443574-1-jimzhao.ai@gmail.com> (raw)
In-Reply-To: <20241023162447.2bf480b4ce590fdeb8b6c52d@linux-foundation.org>
> On Wed, 23 Oct 2024 18:00:32 +0800 Jim Zhao <jimzhao.ai@gmail.com> 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.
> Please tell us more about the userspace-visible effects of this. It
> *sounds* like a serious (but occasional) problem, but that is unclear.
> And, very much relatedly, do you feel this fix is needed in earlier
> (-stable) kernels?
The problem exists in two scenarios:
1. FUSE Write Transition from Inactive to Active
sometimes, active writes require several pauses to ramp up to the appropriate wb_thresh.
As shown in the trace below, both bdi_setpoint and task_ratelimit are 0, means wb_thresh is 0.
The dd process pauses multiple times before reaching a normal state.
dd-1206590 [003] .... 62988.324049: balance_dirty_pages: bdi 0:51: limit=295073 setpoint=259360 dirty=454 bdi_setpoint=0 bdi_dirty=32 dirty_ratelimit=18716 task_ratelimit=0 dirtied=32 dirtied_pause=32 paused=0 pause=4 period=4 think=0 cgroup_ino=1
dd-1206590 [003] .... 62988.332063: balance_dirty_pages: bdi 0:51: limit=295073 setpoint=259453 dirty=454 bdi_setpoint=0 bdi_dirty=33 dirty_ratelimit=18716 task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=4 period=4 think=4 cgroup_ino=1
dd-1206590 [003] .... 62988.340064: balance_dirty_pages: bdi 0:51: limit=295073 setpoint=259526 dirty=454 bdi_setpoint=0 bdi_dirty=34 dirty_ratelimit=18716 task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=4 period=4 think=4 cgroup_ino=1
dd-1206590 [003] .... 62988.348061: balance_dirty_pages: bdi 0:51: limit=295073 setpoint=259531 dirty=489 bdi_setpoint=0 bdi_dirty=35 dirty_ratelimit=18716 task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=4 period=4 think=4 cgroup_ino=1
dd-1206590 [003] .... 62988.356063: balance_dirty_pages: bdi 0:51: limit=295073 setpoint=259531 dirty=490 bdi_setpoint=0 bdi_dirty=36 dirty_ratelimit=18716 task_ratelimit=0 dirtied=1 dirtied_pause=0 paused=0 pause=4 period=4 think=4 cgroup_ino=1
...
2. FUSE with Unstable Network Backends and Occasional Writes
Not easy to reproduce, but when it occurs in this scenario,
it causes the write thread to experience more pauses and longer durations.
Currently, some code is in place to improve this situation, but seems insufficient:
if (dtc->wb_dirty < 8)
{
// ...
}
So the patch raise min wb_thresh to keep the occasional writes won't be blocked and
active writes can rampup the threshold quickly.
--
Thanks,
Jim Zhao
next prev parent reply other threads:[~2024-10-24 6:09 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 10:00 [PATCH] mm/page-writeback: Raise wb_thresh to prevent write blocking with strictlimit Jim Zhao
2024-10-23 23:24 ` Andrew Morton
2024-10-24 6:09 ` Jim Zhao [this message]
2024-10-24 6:20 ` Andrew Morton
2024-10-24 7:29 ` Jim Zhao
2024-10-26 0:02 ` Andrew Morton
2024-11-01 7:17 ` Jim Zhao
2024-11-07 15:32 ` Jan Kara
2024-11-08 3:19 ` Jim Zhao
2024-11-08 22:02 ` Jan Kara
2024-11-12 8:45 ` Jim Zhao
2024-11-13 10:07 ` Jan Kara
2024-11-19 11:44 ` [PATCH v2] mm/page-writeback: raise " Jim Zhao
2024-11-19 12:29 ` [PATCH v2] mm/page-writeback: Raise " Jim Zhao
2024-11-20 8:03 ` Kemeng Shi
2024-11-21 8:05 ` Jim Zhao
2024-12-12 12:32 ` Kemeng Shi
2024-11-20 11:57 ` Jan Kara
2024-11-21 10:20 ` Jim Zhao
2024-11-21 11:49 ` [PATCH v2] mm/page-writeback: raise " Jan Kara
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=20241024060954.443574-1-jimzhao.ai@gmail.com \
--to=jimzhao.ai@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=willy@infradead.org \
/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 NNTP newsgroup(s).