Re: [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY

[Uladzislau Rezki]

On Tue, Mar 10, 2026 at 03:59:14PM -0700, Andrew Morton wrote:
> On Mon, 2 Mar 2026 19:51:25 +0100 Michal Hocko <mhocko@xxxxxxxx> wrote:
> 
> > > I wouldn't do this because:
> > > 
> > > 1. it makes the __GFP_RETRY_MAYFAIL allocations unreliable.
> > 
> > __GFP_RETRY_MAYFAIL doesn't provide any reliability. It just promisses
> > to not OOM while trying hard. I believe this implementation doesn't
> > break that promise.
> > 
> > > 2. The comment at memalloc_noreclaim_save says that it may deplete memory 
> > > reserves: "This should only be used when the caller guarantees the 
> > > allocation will allow more memory to be freed very shortly, i.e. it needs 
> > > to allocate some memory in the process of freeing memory, and cannot 
> > > reclaim due to potential recursion."
> > 
> > yes, this allocation clearly doesn't guaratee to free more memory. That
> > comment is rather dated. Anyway, the crux is to make sure that the
> > allocation is not unbound. The idea behind this decision is that the
> > page tables are only a tiny fraction of the resulting memory allocated.
> > Moreover this virtually allocated space is recycled so over time there
> > should be less and less of page tables allocated as well.
> >  
> > > I think that the cleanest solution to this problem would be to get rid of 
> > > PF_MEMALLOC_NOFS and PF_MEMALLOC_NOIO and instead introduce two per-thread 
> > > variables "gfp_t set_flags" and "gfp_t clear_flags" and set and clear gfp 
> > > flags according to them in the allocator: "gfp = (gfp | 
> > > current->set_flags) & ~current->clear_flags";
> > 
> > We've been through discussions like this one way too many times and the
> > conclusion is that, no this will not work. The gfp space we have and
> > need to support without rewriting a large part of the kernel is simply
> > incompatible with a more sane interface. Yeah, I hate that as well but
> > here we are. We need to be creative to keep sensible and not introduce
> > even more weirdness to the interface.
> 
> Was that an ack?
> 
> I'm still sitting on Mikulas's "mm: allow __GFP_RETRY_MAYFAIL in
> vmalloc", which has
> 
> 	Reported-by: Zdenek Kabelac <zkabelac@xxxxxxxxxx>
> 	Acked-by: SeongJae Park <sj@xxxxxxxxxx>
> 	Reviewed-by: Anshuman Khandual <anshuman.khandual@xxxxxxx>
> 
> I'm unsure how to proceed here?
>
IMO, we should drop the patch as it is not complete and replace it by the

[PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY

https://lore.kernel.org/lkml/20260302114740.2668450-2-urezki@xxxxxxxxx/

--
Uladzislau Rezki