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

[Mike Rapoport]

On Mon, Aug 17, 2026 at 02:21:41PM +0200, Brendan Jackman wrote:
> On Sun Aug 16, 2026 at 12:59 PM CEST, 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 at kernel.org>
> > ---
> >  mm/vmalloc.c | 13 ++++++++-----
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index fc7993db4152..11170d1ee5be 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3361,12 +3361,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);
> >  
> > -	/* HUGE_VMALLOC passes small pages to set_direct_map */
> > -	for (i = 0; i < area->nr_pages; i++)
> > -		if (page_address(area->pages[i]))
> > -			set_direct_map(area->pages[i], 1);
> > +			WARN_ON_ONCE(err);
> 
> Nit: Maybe worth a comment on why this is expected to always succeed?
> I.e. I think we are assuming the only failure mode is allocation but 
> because we know vm_area_page_order() there shouldn't be any allocation?

The assumption we relying on is more involved, but yeah, I can add a
comment. 

-- 
Sincerely yours,
Mike.