On Mon, Aug 12, 2024 at 05:05:24PM +0800, Yafang Shao wrote:
> The PF_MEMALLOC_NORECLAIM flag was introduced in commit eab0af905bfc
> ("mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN"). To complement
> this, let's add two helper functions, memalloc_nowait_{save,restore}, which
> will be useful in scenarios where we want to avoid waiting for memory
> reclamation.
Readahead already uses this context:
static inline gfp_t readahead_gfp_mask(struct address_space *x)
{
return mapping_gfp_mask(x) | __GFP_NORETRY | __GFP_NOWARN;
}
and __GFP_NORETRY means minimal direct reclaim should be performed.
Most filesystems already have GFP_NOFS context from
mapping_gfp_mask(), so how much difference does completely avoiding
direct reclaim actually make under memory pressure?
i.e. doing some direct reclaim without blocking when under memory
pressure might actually give better performance than skipping direct
reclaim and aborting readahead altogether....
This really, really needs some numbers (both throughput and IO
latency histograms) to go with it because we have no evidence either
way to determine what is the best approach here.
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
