linux-kernel - Re: [PATCH v3 10/10] Documentation/gpu/drm-mm: Add THP paragraph to GEM mapping section

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aOGiU77k1XPb9W9M@archie.me>
Date: Sun, 5 Oct 2025 05:40:19 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Loïc Molinari <loic.molinari@...labora.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Tvrtko Ursulin <tursulin@...ulin.net>,
	Boris Brezillon <boris.brezillon@...labora.com>,
	Rob Herring <robh@...nel.org>, Steven Price <steven.price@....com>,
	Liviu Dudau <liviu.dudau@....com>, Melissa Wen <mwen@...lia.com>,
	Maíra Canal <mcanal@...lia.com>,
	Hugh Dickins <hughd@...gle.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Mikołaj Wasiak <mikolaj.wasiak@...el.com>,
	Christian Brauner <brauner@...nel.org>,
	Nitin Gote <nitin.r.gote@...el.com>,
	Andi Shyti <andi.shyti@...ux.intel.com>,
	Christopher Healy <healych@...zon.com>
Cc: linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	intel-gfx@...ts.freedesktop.org, linux-mm@...ck.org,
	kernel@...labora.com
Subject: Re: [PATCH v3 10/10] Documentation/gpu/drm-mm: Add THP paragraph to
 GEM mapping section

On Sat, Oct 04, 2025 at 11:30:53AM +0200, Loïc Molinari wrote:
> @@ -290,7 +292,7 @@ The open and close operations must update the GEM object reference
>  count. Drivers can use the drm_gem_vm_open() and drm_gem_vm_close() helper
>  functions directly as open and close handlers.
>  
> -The fault operation handler is responsible for mapping individual pages
> +The fault operation handlers are responsible for mapping individual pages
>  to userspace when a page fault occurs. Depending on the memory
>  allocation scheme, drivers can allocate pages at fault time, or can
>  decide to allocate memory for the GEM object at the time the object is
> @@ -299,6 +301,19 @@ created.
>  Drivers that want to map the GEM object upfront instead of handling page
>  faults can implement their own mmap file operation handler.
>  
> +In order to reduce page table overhead, if the internal shmem mountpoint
> +"shm_mnt" is configured to use transparent huge pages (for builds with
> +CONFIG_TRANSPARENT_HUGEPAGE enabled) and if the shmem backing store
> +manages to allocate huge pages, faulty addresses within huge pages will
> +be mapped into the tables using the huge page fault handler. In such
> +cases, mmap() user address alignment for GEM objects is handled by
> +providing a custom get_unmapped_area properly forwarding to the shmem
> +backing store. For most drivers, which don't create a huge mountpoint by
> +default or through a module parameter, transparent huge pages can be
> +enabled by either setting the "transparent_hugepage_shmem" kernel
> +parameter or the "/sys/kernel/mm/transparent_hugepage/shmem_enabled"
> +sysfs knob.
> +
>  For platforms without MMU the GEM core provides a helper method
>  drm_gem_dma_get_unmapped_area(). The mmap() routines will call this to get a
>  proposed address for the mapping.
 
LGTM, thanks!

Reviewed-by: Bagas Sanjaya <bagasdotme@...il.com>

-- 
An old man doll... just what I always wanted! - Clara

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)