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

[Uladzislau Rezki]

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