On Fri, 28 Nov 2025 19:52:52 +0100 Loïc Molinari <[email protected]> wrote:
> Add a paragraph 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 > > Signed-off-by: Loïc Molinari <[email protected]> > Reviewed-by: Bagas Sanjaya <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> > --- > Documentation/gpu/drm-mm.rst | 22 +++++++++++++++++----- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst > index d55751cad67c..d69eab0b4093 100644 > --- a/Documentation/gpu/drm-mm.rst > +++ b/Documentation/gpu/drm-mm.rst > @@ -290,15 +290,27 @@ 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 > -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 > -created. > +The fault operation handler is responsible for mapping 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 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 > +managed to allocate a huge page for a faulty address, the fault handler > +will first attempt to insert that huge page into the VMA before falling > +back to individual page insertion. mmap() user address alignment for GEM > +objects is handled by providing a custom get_unmapped_area file > +operation which forwards 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.
