Re: [PATCH] ext4_sb_breadahead_unmovable: Change to be no-blocking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux