On Wed, Aug 14, 2024 at 8:28 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> 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?
Besides the __GFP_NOFS , ~__GFP_DIRECT_RECLAIM also implies
__GPF_NOIO. If we don't set __GPF_NOIO, the readahead can wait for IO,
right?
>
> 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
--
Regards
Yafang
