From: Matthew Wilcox <willy@infradead.org>
To: Hui Zhu <teawaterz@linux.alibaba.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, akpm@linux-foundation.org,
jack@suse.cz, yi.zhang@huawei.com, hare@suse.de,
p.raghav@samsung.com, ritesh.list@gmail.com, mpatocka@redhat.com,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-ext4@vger.kernel.org, teawater@antgroup.com,
teawater@gmail.com
Subject: Re: [PATCH] ext4_sb_breadahead_unmovable: Change to be no-blocking
Date: Fri, 11 Aug 2023 05:08:56 +0100 [thread overview]
Message-ID: <ZNW0WF/K8HS8AIu5@casper.infradead.org> (raw)
In-Reply-To: <20230811035705.3296-1-teawaterz@linux.alibaba.com>
On Fri, Aug 11, 2023 at 03:57:05AM +0000, Hui Zhu wrote:
> Encountered an issue where a large number of filesystem reads and writes
> occurred suddenly within a container. At the same time, other tasks on
> the same host that were performing filesystem read and write operations
> became blocked. It was observed that many of the blocked tasks were
> blocked on the ext4 journal lock. For example:
> PID: 171453 TASK: ffff926566c9440 CPU: 54 COMMAND: "Thread"
>
> Meanwhile, it was observed that the task holding the ext4 journal lock
> was blocked for an extended period of time on "shrink_page_list" due to
> "ext4_sb_breadahead_unmovable".
>
> The function "grow_dev_page" increased the gfp mask with "__GFP_NOFAIL",
> causing longer blocking times.
> /*
> * XXX: __getblk_slow() can not really deal with failure and
> * will endlessly loop on improvised global reclaim. Prefer
> * looping in the allocator rather than here, at least that
> * code knows what it's doing.
> */
> gfp_mask |= __GFP_NOFAIL;
> However, "ext4_sb_breadahead_unmovable" is a prefetch function and
> failures are acceptable.
That's a really good point.
> Therefore, this commit changes "ext4_sb_breadahead_unmovable" to be
> non-blocking, removing "__GFP_DIRECT_RECLAIM" from the gfp mask in the
> "grow_dev_page" function if caller is ext4_sb_breadahead_unmovable to
> alleviate memory-related blocking issues.
Uh, not like this though. Fix the gfp flags in the callers instead of
working this new "bool" flag through the buffer head layers.
next prev parent reply other threads:[~2023-08-11 4:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 3:57 [PATCH] ext4_sb_breadahead_unmovable: Change to be no-blocking Hui Zhu
2023-08-11 4:08 ` Matthew Wilcox [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-08-11 7:15 Hui Zhu
2023-08-11 7:21 ` Hui Zhu
2023-08-11 16:49 ` Matthew Wilcox
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=ZNW0WF/K8HS8AIu5@casper.infradead.org \
--to=willy@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=p.raghav@samsung.com \
--cc=ritesh.list@gmail.com \
--cc=teawater@antgroup.com \
--cc=teawater@gmail.com \
--cc=teawaterz@linux.alibaba.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=yi.zhang@huawei.com \
/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