Re: [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY

[Andrew Morton]

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?