Re: [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY

[Michal Hocko]

On Wed 11-03-26 09:42:29, Uladzislau Rezki wrote:
> 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

Yes, that patch is not really correct as it allows to trigger OOM killer
during pte allocation.
 
> [PATCH] vmalloc: support __GFP_RETRY_MAYFAIL and __GFP_NORETRY
> 
> https://lore.kernel.org/lkml/20260302114740.2668450-2-urezki@xxxxxxxxx/

ack
-- 
Michal Hocko
SUSE Labs