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

["Loïc Molinari" <loic.molinari@collabora.com>]

Hi Maíra,

On 01/12/2025 14:27, Maíra Canal wrote:
> Hi Loïc,
> 
> On 28/11/25 15:52, Loïc Molinari 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 <loic.molinari@collabora.com>
>> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
>> ---
>>   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.
> 
> It would be nice to have a paragraph about the use of the huge tmpfs
> mountpoint helpers (maybe in the "GEM Objects Creation" section?).

Thanks for the review.

I've added a few words about the drm_gem_huge_huge_mnt() helper into the 
"GEM Objects Creation" section in patch series v11. I've also just 
realized that I added your R-b to that commit without you asking for 
it... sorry for that. I'll remove it in v12 unless you explicitly ask to 
let it there.

Regards,
Loïc

> Best Regards,
> - Maíra
> 
>> +
>>   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.
>