Re: [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node()

Michal Hocko
2025-07-08T15:22:59Z

On Tue 08-07-25 14:27:57, Uladzislau Rezki wrote:
> On Mon, Jul 07, 2025 at 09:13:04AM +0200, Michal Hocko wrote:
> > On Fri 04-07-25 17:25:36, Uladzislau Rezki wrote:
> > > This patch makes __vmalloc_area_node() to correctly handle non-blocking
> > > allocation requests, such as GFP_ATOMIC and GFP_NOWAIT. Main changes:
> > >
> > > - nested_gfp flag follows the same non-blocking constraints
> > > as the primary gfp_mask, ensuring consistency and avoiding
> > > sleeping allocations in atomic contexts.
> > >
> > > - if blocking is not allowed, __GFP_NOFAIL is forcibly cleared
> > > and warning is issued if it was set, since __GFP_NOFAIL is
> > > incompatible with non-blocking contexts;
> > >
> > > - Add a __GFP_HIGHMEM to gfp_mask only for blocking requests
> > > if there are no DMA constraints.
> > >
> > > - in non-blocking mode we use memalloc_noreclaim_save/restore()
> > > to prevent reclaim related operations that may sleep while
> > > setting up page tables or mapping pages.
> > >
> > > This is particularly important for page table allocations that
> > > internally use GFP_PGTABLE_KERNEL, which may sleep unless such
> > > scope restrictions are applied. For example:
> > >
> > > <snip>
> > > #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO)
> > >
> > > __pte_alloc_kernel()
> > > pte_alloc_one_kernel(&init_mm);
> > > pagetable_alloc_noprof(GFP_PGTABLE_KERNEL & ~__GFP_HIGHMEM, 0);
> > > <snip>
> >
> > The changelog doesn't explain the actual implementation and that is
> > really crucial here. You rely on memalloc_noreclaim_save (i.e.
> > PF_MEMALLOC) to never trigger memory reclaim but you are not explaining
> > how do you prevent from the biggest caveat of this interface. Let me
> > quote the documentation
> > * Users of this scope have to be extremely careful to not deplete the reserves
> > * completely and implement a throttling mechanism which controls the
> > * consumption of the reserve based on the amount of freed memory. Usage of a
> > * pre-allocated pool (e.g. mempool) should be always considered before using
> > * this scope.
> >
> I am aware about that comment. I had same concern about this, but it
> looks like i/you may overshot here. Yes, we have access to memory
> resrves but this only for page-table manipulations, i.e. to allocate
> a page for 5-level page table structure. We have PGD, P4D, PUD, PMD
> and PTE which is the lowest level and which needs pages the most.
>
> As i see we do not free pages at least on PTE level, it means that
> an address space is populated forward only and never shrink back.
> Most of the time you do not need to allocate, this mostly occurs
> initially after the boot.

You are right, I have misread the patch. I thought this includes
vm_area_alloc_pages as well but you are right this is only for page
tables and that seems much more reasonable. Having that outlined in the
changelog would have helped ;)
--
Michal Hocko
SUSE Labs