[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251004093054.21388-11-loic.molinari@collabora.com>
Date: Sat, 4 Oct 2025 11:30:53 +0200
From: Loïc Molinari <loic.molinari@...labora.com>
To: 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>,
Loïc Molinari <loic.molinari@...labora.com>,
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: [PATCH v3 10/10] Documentation/gpu/drm-mm: Add THP paragraph to GEM mapping section
Add a paragraph to the GEM objects mapping section explaining how
transparent huge pages are handled by GEM.
Signed-off-by: Loïc Molinari <loic.molinari@...labora.com>
---
Documentation/gpu/drm-mm.rst | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index d55751cad67c..0ce6e27f8463 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -283,6 +283,8 @@ made up of several fields, the more interesting ones being:
void (*open)(struct vm_area_struct * area);
void (*close)(struct vm_area_struct * area);
vm_fault_t (*fault)(struct vm_fault *vmf);
+ vm_fault_t (*huge_fault)(struct vm_fault *vmf,
+ unsigned int order);
};
@@ -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.
--
2.47.3
Powered by blists - more mailing lists