Re: [PATCH 8/8] mm: Drop __GFP_DIRECT_RECLAIM flag if PF_MEMALLOC is set

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Aug 07, 2025 at 01:58:20PM +0200, Michal Hocko wrote:
> On Thu 07-08-25 09:58:10, Uladzislau Rezki wrote:
> > The memory allocator already avoids reclaim when PF_MEMALLOC is set.
> > Clear __GFP_DIRECT_RECLAIM explicitly to suppress might_alloc() warnings
> > to make more correct behavior.
> 
> Rather than chaning the gfp mask would it make more sense to update
> might_alloc instead?
> 
Hm.. I was thinking about it but decided to drop the __GFP_DIRECT_RECLAIM
instead just to guarantee a no-reclaim behaviour, as it is written now to
the flag.

From the other hand after this patch we would have some unneeded/dead
checks(if i do not missing anything). For example:

[1]
    WARN_ON_ONCE(!can_direct_reclaim);
    /*
     * PF_MEMALLOC request from this context is rather bizarre
     * because we cannot reclaim anything and only can loop waiting
     * for somebody to do a work for us.
     */
    WARN_ON_ONCE(current->flags & PF_MEMALLOC);
[2]
    /* no reclaim without waiting on it */
    if (!(gfp_mask & __GFP_DIRECT_RECLAIM))
        return false;

    /* this guy won't enter reclaim */
    if (current->flags & PF_MEMALLOC)
        return false;

[3]
    /* Caller is not willing to reclaim, we can't balance anything */
    if (!can_direct_reclaim)
        goto nopage;

    /* Avoid recursion of direct reclaim */
    if (current->flags & PF_MEMALLOC)
        goto nopage;
etc.

But, yes, might_alloc() can be modified also.

--
Uladzislau Rezki