__vmalloc() and no-block support

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

Posted by Uladzislau Rezki (Sony) 1 month, 4 weeks ago

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.

Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
 include/linux/sched/mm.h | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
index 2201da0afecc..8332fc09f8ac 100644
--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -246,12 +246,14 @@ static inline bool in_vfork(struct task_struct *tsk)
  * PF_MEMALLOC_NOIO implies GFP_NOIO
  * PF_MEMALLOC_NOFS implies GFP_NOFS
  * PF_MEMALLOC_PIN  implies !GFP_MOVABLE
+ * PF_MEMALLOC      implies !__GFP_DIRECT_RECLAIM
  */
 static inline gfp_t current_gfp_context(gfp_t flags)
 {
 	unsigned int pflags = READ_ONCE(current->flags);
 
-	if (unlikely(pflags & (PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS | PF_MEMALLOC_PIN))) {
+	if (unlikely(pflags & (PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS |
+			PF_MEMALLOC_PIN | PF_MEMALLOC))) {
 		/*
 		 * NOIO implies both NOIO and NOFS and it is a weaker context
 		 * so always make sure it makes precedence
@@ -263,6 +265,9 @@ static inline gfp_t current_gfp_context(gfp_t flags)
 
 		if (pflags & PF_MEMALLOC_PIN)
 			flags &= ~__GFP_MOVABLE;
+
+		if (pflags & PF_MEMALLOC)
+			flags &= ~__GFP_DIRECT_RECLAIM;
 	}
 	return flags;
 }
-- 
2.39.5

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

Posted by Michal Hocko 1 month, 4 weeks ago

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?

-- 
Michal Hocko
SUSE Labs

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

Posted by Uladzislau Rezki 1 month, 3 weeks ago

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

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

Posted by Michal Hocko 1 month, 3 weeks ago

On Fri 08-08-25 15:12:45, Uladzislau Rezki wrote:
> 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.

I do not have a _strong_ preference but my slight preference would be to
deal with this in might_alloc. Not sure what other think.

-- 
Michal Hocko
SUSE Labs

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

Posted by Uladzislau Rezki 1 month, 3 weeks ago

On Fri, Aug 08, 2025 at 04:16:04PM +0200, Michal Hocko wrote:
> On Fri 08-08-25 15:12:45, Uladzislau Rezki wrote:
> > 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.
> 
> I do not have a _strong_ preference but my slight preference would be to
> deal with this in might_alloc. Not sure what other think.
> 
No problem, that i can easily switch to.

--
Uladzisau Rezki