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

From: Uladzislau Rezki
Date: Wed Jul 09 2025 - 07:22:15 EST


On Tue, Jul 08, 2025 at 05:22:52PM +0200, Michal Hocko wrote:
> 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 ;)
>
I will update the commit message in more detail in my next version.

Thank you for!

--
Uladzislau Rezki