tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Documentation/gpu/drm-mm: Add THP paragraph to GEM mapping section

Add a paragraph to the GEM Objects Creation section about the
drm_gem_huge_mnt_create() helper and to the GEM objects mapping
section explaining how transparent huge pages are handled by GEM.

v4:
- fix wording after huge_pages handler removal

v6:
- fix wording after map_pages handler removal

v11:
- mention drm_gem_huge_mnt_create() helper
- add Boris and Maíra R-bs

Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20251205182231.194072-11-loic.molinari@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

authored by

Loïc Molinari and committed by
Boris Brezillon 70478348 c12e9fcb

+23 -6
+23 -6
Documentation/gpu/drm-mm.rst
··· 155 155 requested size and store it into the struct :c:type:`struct 156 156 drm_gem_object <drm_gem_object>` filp field. The memory is 157 157 used as either main storage for the object when the graphics hardware 158 - uses system memory directly or as a backing store otherwise. 158 + uses system memory directly or as a backing store otherwise. Drivers 159 + can call drm_gem_huge_mnt_create() to create, mount and use a huge 160 + shmem mountpoint instead of the default one ('shm_mnt'). For builds 161 + with CONFIG_TRANSPARENT_HUGEPAGE enabled, further calls to 162 + drm_gem_object_init() will let shmem allocate huge pages when 163 + possible. 159 164 160 165 Drivers are responsible for the actual physical pages allocation by 161 166 calling shmem_read_mapping_page_gfp() for each page. ··· 295 290 count. Drivers can use the drm_gem_vm_open() and drm_gem_vm_close() helper 296 291 functions directly as open and close handlers. 297 292 298 - The fault operation handler is responsible for mapping individual pages 299 - to userspace when a page fault occurs. Depending on the memory 300 - allocation scheme, drivers can allocate pages at fault time, or can 301 - decide to allocate memory for the GEM object at the time the object is 302 - created. 293 + The fault operation handler is responsible for mapping pages to 294 + userspace when a page fault occurs. Depending on the memory allocation 295 + scheme, drivers can allocate pages at fault time, or can decide to 296 + allocate memory for the GEM object at the time the object is created. 303 297 304 298 Drivers that want to map the GEM object upfront instead of handling page 305 299 faults can implement their own mmap file operation handler. 300 + 301 + In order to reduce page table overhead, if the internal shmem mountpoint 302 + "shm_mnt" is configured to use transparent huge pages (for builds with 303 + CONFIG_TRANSPARENT_HUGEPAGE enabled) and if the shmem backing store 304 + managed to allocate a huge page for a faulty address, the fault handler 305 + will first attempt to insert that huge page into the VMA before falling 306 + back to individual page insertion. mmap() user address alignment for GEM 307 + objects is handled by providing a custom get_unmapped_area file 308 + operation which forwards to the shmem backing store. For most drivers, 309 + which don't create a huge mountpoint by default or through a module 310 + parameter, transparent huge pages can be enabled by either setting the 311 + "transparent_hugepage_shmem" kernel parameter or the 312 + "/sys/kernel/mm/transparent_hugepage/shmem_enabled" sysfs knob. 306 313 307 314 For platforms without MMU the GEM core provides a helper method 308 315 drm_gem_dma_get_unmapped_area(). The mmap() routines will call this to get a