Re: [PATCH v3 4/6] mm/vmalloc: make set_area_direct_map HUGE_VMAP friendly

[Mike Rapoport]

On Tue, Sep 08, 2026 at 01:48:36PM +0200, David Hildenbrand (Arm) wrote:
> On 9/8/26 13:12, Mike Rapoport wrote:
> > On Tue, Sep 08, 2026 at 12:41:48PM +0200, David Hildenbrand (Arm) wrote:
> >> On 9/3/26 11:28, Mike Rapoport (Microsoft) wrote:
> >>> set_area_direct_map() always updates direct map alias permissions in
> >>> single page increments.
> >>>
> >>> For HUGE_VMAP areas it's suboptimal. Not only the loop in
> >>> set_area_direct_map() needlessly has more iterations (e.g times 512 on
> >>> x86), but it also causes fragmentation of the direct map that could be
> >>> avoided for the HUGE_VMAP areas populated with large pages.
> >>>
> >>> All pages in an area are always of the same order: either same-order
> >>> large pages when VM_ALLOW_HUGE_VMAP is set and all huge pages were
> >>> successfully allocated, or order-0 page when VM_ALLOW_HUGE_VMAP is
> >>> cleared or when huge pages allocation fails and fallback path is taken.
> >>>
> >>> Instead of updating the direct map permissions for every order-0 page in
> >>> an area, use the area's page_order as the loop increment and update the
> >>> large pages in one call to set_direct_map_{invalid,default}_noflush().
> >>>
> >>> Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> >>> ---
> >>>  mm/vmalloc.c | 13 ++++++++-----
> >>>  1 file changed, 8 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> >>> index 5506b180f5c27..6ed6c160abed7 100644
> >>> --- a/mm/vmalloc.c
> >>> +++ b/mm/vmalloc.c
> >>> @@ -3367,12 +3367,15 @@ static inline void set_area_direct_map(const struct vm_struct *area,
> >>>  				       int (*set_direct_map)(struct page *page,
> >>>  							     unsigned int nr))
> >>>  {
> >>> -	unsigned long i;
> >>> +	unsigned int nr = (1U << vm_area_page_order(area));
> >>> +
> >>> +	for (unsigned long i = 0; i < area->nr_pages; i += nr) {
> >>> +		if (page_address(area->pages[i])) {
> >>> +			int err = set_direct_map(area->pages[i], nr);
> >>
> >> Do we really expect some pages to have a directmap and others not?
> > 
> > Every page in the area can be allocated separately and
> > __vmalloc_area_node() has
> > 
> > 	if (!(gfp_mask & (GFP_DMA | GFP_DMA32)))
> > 		gfp_mask |= __GFP_HIGHMEM;
> > 
> > so generally speaking yes :)
> 
> Ah, I was thinking in terms of HUGE_VMAP, because there we sure would expect
> all-or-nothing, right?

Even with VM_ALLOW_HUGE_VMAP an area may be backed by highmem pages. When
huge allocations are disabled either because an architecture does not
support them or nohugevmalloc=no, vmalloc(VM_ALLOW_HUGE_VMAP) silently
falls back to order-0 allocations.
 
> -- 
> Cheers,
> 
> David

-- 
Sincerely yours,
Mike.