On Tue, Feb 24, 2026 at 05:07:43PM +0100, Uladzislau Rezki wrote:
> On Tue, Feb 24, 2026 at 04:51:35PM +0100, Michal Hocko wrote:
> > On Tue 24-02-26 16:44:43, Michal Hocko wrote:
> > > On Tue 24-02-26 16:38:01, Uladzislau Rezki wrote:
> > [...]
> > > > I do not have a strong opinion about workaround you noted. Maybe Mikulas
> > > > can switch to NOWAIT flag instead.
> > >
> > > using NOWAIT for the full vmalloc allocation would be just too easy to
> > > fail under moderate memory pressure.
> > >
> > > The real question is whether we want to provide some sort of backoff
> > > early but not way too easily allocation semantic for vmalloc. If yes we
> > > need to get creative in the vmalloc internals rather than expect callers
> > > to be working around that on their side. History has proven that this
> > > just leads to tech. dept and more work later on.
> >
> > Just to make sure we are on the same page I mean something like this
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 61caa55a4402..791366fe44e2 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3798,6 +3798,8 @@ static void defer_vm_area_cleanup(struct vm_struct
> > *area)
> > * non-blocking (no __GFP_DIRECT_RECLAIM) - memalloc_noreclaim_save()
> > * GFP_NOFS - memalloc_nofs_save()
> > * GFP_NOIO - memalloc_noio_save()
> > + * __GFP_RETRY_MAYFAIL, __GFP_NORETRY - memalloc_noreclaim_save() to
> > prevent
> > + * OOMs
> > *
> > * Returns a flag cookie to pair with restore.
> > */
> > @@ -3806,7 +3808,7 @@ memalloc_apply_gfp_scope(gfp_t gfp_mask)
> > {
> > unsigned int flags = 0;
> >
> > - if (!gfpflags_allow_blocking(gfp_mask))
> > + if (!gfpflags_allow_blocking(gfp_mask) || (gfp_mask &
> > (__GFP_RETRY_MAYFAIL|__GFP_NORETRY)))
> > flags = memalloc_noreclaim_save();
> > else if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO)
> > flags = memalloc_nofs_save();
> > @@ -3940,7 +3942,8 @@ static void *__vmalloc_area_node(struct vm_struct
> > *area, gfp_t gfp_mask,
> > * GFP_KERNEL_ACCOUNT. Xfs uses __GFP_NOLOCKDEP.
> > */
> > #define GFP_VMALLOC_SUPPORTED (GFP_KERNEL | GFP_ATOMIC | GFP_NOWAIT |\
> > - __GFP_NOFAIL | __GFP_ZERO | __GFP_NORETRY |\
> > + __GFP_NOFAIL | __GFP_ZERO | |\
> > + __GFP_NORETRY | __GFP_RETRY_MAYFAIL |\
> > GFP_NOFS | GFP_NOIO | GFP_KERNEL_ACCOUNT |\
> > GFP_USER | __GFP_NOLOCKDEP)
> >
> > @@ -3971,12 +3974,15 @@ static gfp_t vmalloc_fix_flags(gfp_t flags)
> > * virtual range with protection @prot.
> > *
> > * Supported GFP classes: %GFP_KERNEL, %GFP_ATOMIC, %GFP_NOWAIT,
> > - * %GFP_NOFS and %GFP_NOIO. Zone modifiers are not supported.
> > + * %__GFP_RETRY_MAYFAIL, %__GFP_NORETRY, %GFP_NOFS and %GFP_NOIO.
> > + * Zone modifiers are not supported.
> > * Please note %GFP_ATOMIC and %GFP_NOWAIT are supported only
> > * by __vmalloc().
> > *
> > - * Retry modifiers: only %__GFP_NOFAIL is supported; %__GFP_NORETRY
> > - * and %__GFP_RETRY_MAYFAIL are not supported.
> > + * Retry modifiers: only %__GFP_NOFAIL is fully supported;
> > + * %__GFP_NORETRY and %__GFP_RETRY_MAYFAIL are supported with limitation,
> > + * i.e. page tables are allocated with NOWAIT semantic so they might fail
> > + * under moderate memory pressure.
> > *
> > * %__GFP_NOWARN can be used to suppress failure messages.
> > *
> >
> Yep, i got your intention correctly. It would eliminate the problem
> with page tables allocations :)
>
If no objection, we can go the way which was proposed by Michal and
support __GFP_RETRY_MAYFAIL flag.
Mikulas is that possible for you to resend the patch including
Michal changes(unless Michal wants to send the patch on his own)?
--
Uladzislau Rezki
