linux-kernel - Re: [PATCH RFC] mm/vmap: map contiguous pages in batches whenever possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aS7xnhxNhJ71cJRb@pc636>
Date: Tue, 2 Dec 2025 15:03:10 +0100
From: Uladzislau Rezki <urezki@...il.com>
To: Barry Song <21cnbao@...il.com>
Cc: Uladzislau Rezki <urezki@...il.com>, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-media@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
	linux-kernel@...r.kernel.org, Barry Song <v-songbaohua@...o.com>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	John Stultz <jstultz@...gle.com>,
	Maxime Ripard <mripard@...nel.org>
Subject: Re: [PATCH RFC] mm/vmap: map contiguous pages in batches whenever
 possible

On Tue, Dec 02, 2025 at 06:05:56AM +0800, Barry Song wrote:
> On Mon, Dec 1, 2025 at 7:08 PM Uladzislau Rezki <urezki@...il.com> wrote:
> >
> > On Fri, Nov 28, 2025 at 04:43:54AM +0800, Barry Song wrote:
> > > > >
> > > > > +     /*
> > > > > +      * Some users may allocate pages from high-order down to order 0.
> > > > > +      * We roughly check if the first page is a compound page. If so,
> > > > > +      * there is a chance to batch multiple pages together.
> > > > > +      */
> > > > >       if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) ||
> > > > > -                     page_shift == PAGE_SHIFT)
> > > > > +                     (page_shift == PAGE_SHIFT && !PageCompound(pages[0])))
> > > > >
> > > > Do we support __GFP_COMP as vmalloc/vmap flag? As i see from latest:
> > >
> > > This is not the case for vmalloc, but applies to dma-bufs that are allocated
> > > using alloc_pages() with GFP_COMP.
> > >
> > > #define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO)
> > > #define HIGH_ORDER_GFP  (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
> > >                                 | __GFP_NORETRY) & ~__GFP_RECLAIM) \
> > >                                 | __GFP_COMP)
> > >
> > > >
> > > > /*
> > > >  * See __vmalloc_node_range() for a clear list of supported vmalloc flags.
> > > >  * This gfp lists all flags currently passed through vmalloc. Currently,
> > > >  * __GFP_ZERO is used by BPF and __GFP_NORETRY is used by percpu. Both drm
> > > >  * and BPF also use GFP_USER. Additionally, various users pass
> > > >  * GFP_KERNEL_ACCOUNT. Xfs uses __GFP_NOLOCKDEP.
> > > >  */
> > > > #define GFP_VMALLOC_SUPPORTED (GFP_KERNEL | GFP_ATOMIC | GFP_NOWAIT |\
> > > >                                __GFP_NOFAIL |  __GFP_ZERO | __GFP_NORETRY |\
> > > >                                GFP_NOFS | GFP_NOIO | GFP_KERNEL_ACCOUNT |\
> > > >                                GFP_USER | __GFP_NOLOCKDEP)
> > > >
> > > > Could you please clarify when PageCompound(pages[0]) returns true?
> > > >
> > >
> > > In this case, dma-buf attempts to allocate as many compound high-order pages
> > > as possible, falling back to 0-order allocations if necessary.
> > >
> > OK, it is folio who uses it.
> >
> > > Then, dma_buf_vmap() is called by the GPU drivers:
> > >
> > >  1    404  drivers/accel/amdxdna/amdxdna_gem.c <<amdxdna_gem_obj_vmap>>
> > >              dma_buf_vmap(abo->dma_buf, map);
> > >    2   1568  drivers/dma-buf/dma-buf.c <<dma_buf_vmap_unlocked>>
> > >              ret = dma_buf_vmap(dmabuf, map);
> > >    3    354  drivers/gpu/drm/drm_gem_shmem_helper.c
> > > <<drm_gem_shmem_vmap_locked>>
> > >              ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
> > >    4     85  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
> > > <<etnaviv_gem_prime_vmap_impl>>
> > >              ret = dma_buf_vmap(etnaviv_obj->base.import_attach->dmabuf, &map);
> > >    5    433  drivers/gpu/drm/vmwgfx/vmwgfx_blit.c <<map_external>>
> > >              ret = dma_buf_vmap(bo->tbo.base.dma_buf, map);
> > >    6     88  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c <<vmw_gem_vmap>>
> > >              ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
> > >
> > Thank you for clarification. That would be good to reflect it in the
> > commit message. Also, please note that:
> 
> Sure.
> 
> >
> > >       if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) ||
> > > -                     page_shift == PAGE_SHIFT)
> > > +                     (page_shift == PAGE_SHIFT && !PageCompound(pages[0])))
> > >
> > we rely on page_shift == PAGE_SHIFT condition for the non-sleep vmalloc()
> > allocations(GFP_ATOMIC, GFP_NOWAIT), so we go via vmap_small_pages_range_noflush()
> > path. Your patch adds !PageCompound(pages[0]) also. It is not a problem
> > since it is vmap() path but we need to comment that.
> 
> Sure. Would the following work?
> 
>         /*
>          * For vmap(), users may allocate pages from high orders down
> to order 0,
>          * while always using PAGE_SHIFT as the page_shift.
>          * We first check whether the initial page is a compound page. If so,
>          * there may be an opportunity to batch multiple pages together.
>          */
>         if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) ||
>                         (page_shift == PAGE_SHIFT && !PageCompound(pages[0])))
>                 return vmap_small_pages_range_noflush(addr, end, prot, pages);
> 
Sounds good!

Thank you.

--
Uladzislau Rezki