On Wed, Aug 14, 2024 at 10:19:36AM +0800, Yafang Shao wrote:
> 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?
There's a *lot* more difference between __GFP_NORETRY and
__GFP_NOWAIT than just __GFP_NOIO. I don't need you to try to
describe to me what the differences are; What I'm asking you is this:
> > 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.
Put simply: does the existing readahead mechanism give better results
than the proposed one, and if so, why wouldn't we just reenable
readahead unconditionally instead of making it behave differently
for this specific case?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
