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 :)
--
Uladzislau Rezki
