Re: [PATCH v3] docs: update THP admin guide about non-tmpfs filesystem support

[David Hildenbrand <david@redhat.com>]

On 04.04.25 21:44, Daniel Gomez wrote:
> On Fri, Apr 04, 2025 at 09:07:23PM +0100, David Hildenbrand wrote:
>> On 04.04.25 19:58, Luis Chamberlain wrote:
>>> On Fri, Apr 04, 2025 at 06:18:12PM +0200, David Hildenbrand wrote:
>>>> On 04.04.25 17:32, Luis Chamberlain wrote:
>>>>> On Fri, Apr 04, 2025 at 04:06:57PM +0200, Pankaj Raghav (Samsung) wrote:
>>>>>> From: Pankaj Raghav <p.raghav@samsung.com>
>>>>>>
>>>>>> THP support for non-tmpfs filesystem has been around for some time now.
>>>>>> Update the admin guide to reflect it.
>>>>>>
>>>>>> While we are at it, move FilePmdMapped to previous paragraph for clarity,
>>>>>> and clarify ShmemPmdMapped & ShmemHugePage.
>>>>>>
>>>>>> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
>>>>>> Acked-by: David Hildenbrand <david@redhat.com>
>>>>>> ---
>>>>>>
>>>>>> Changes since v2:
>>>>>> - Address comment from Bagas Sanjaya
>>>>>> - Squash commits and Ack from David
>>>>>>
>>>>>>     Documentation/admin-guide/mm/transhuge.rst | 22 +++++++++++++++-------
>>>>>>     1 file changed, 15 insertions(+), 7 deletions(-)
>>>>>>
>>>>>> diff --git a/Documentation/admin-guide/mm/transhuge.rst b/Documentation/admin-guide/mm/transhuge.rst
>>>>>> index dff8d5985f0f..f8aae64e38d0 100644
>>>>>> --- a/Documentation/admin-guide/mm/transhuge.rst
>>>>>> +++ b/Documentation/admin-guide/mm/transhuge.rst
>>>>>> @@ -12,8 +12,8 @@ using huge pages for the backing of virtual memory with huge pages
>>>>>>     that supports the automatic promotion and demotion of page sizes and
>>>>>>     without the shortcomings of hugetlbfs.
>>>>>> -Currently THP only works for anonymous memory mappings and tmpfs/shmem.
>>>>>> -But in the future it can expand to other filesystems.
>>>>>> +Currently, THP only works for anonymous memory mappings, tmpfs/shmem and
>>>>>> +filesystems that support large folios.
>>>>>
>>>>> That seems to allude that THP can be supported on filesystems
>>>>> that suppor large folios. I don't think we want to call that THP
>>>>> and that can confuse folks. Leaving "currently" also seems to
>>>>> indicate that there is more work to be done for THP for filesystems
>>>>> but that's not true as well. So how about something like:
>>>>>
>>>>> THP only works for anonymous memory mappings, and the tmpfs/shmem is the only
>>>>> filesystem to support it. The alternative to THP for other filesystems is to
>>>>> support large folios and with it you can end up using huge pages
>>>>
>>>> That makes things more complicated without a good reason.
>>>>
>>>> See CONFIG_READ_ONLY_THP_FOR_FS as an early usage of the term "THP" for
>>>> stuff we have in the pagecache.
>>>
>>> OK.
>>>
>>>> (with large folios we now properly implement
>>>> this concept, and support more than only PMD size)
>>>
>>> Do we really want to call large folio support on filesystems THP?
>>
>> Good question.
>>
>> "folio" is just the metadata we currently use to manage a chunk of memory,
>> and a "large folio" is one that spans more than a single page -- huge page,
>> large page, super page, ... in the past the metadata for that used to be a
>> complicated piece of "compound page". In the future, we might call it
>> differently (struct file_mem ?), who knows.
>>
>> So "large folio" support in a fs allows for the usage of these larger chunks
>> of memory (huge pages).
> 
> I'm a bit confused here. I thought the term 'huge pages' referred to specific
> page table level like PMD, PUD, or PGD (and not PTE). And "large folio" term can
> span up to anything (currently up to PMD). Could you clarify if I'm
> misunderstanding something?

The transhuge.rst is still a bit inconsistent and confusing, but we 
started generalizing the concept to special-case "Traditional THPs" to 
be PMD-sized THPs. See the description about mTHP in the document.

If a small folio represents a single page, then a large folio represents 
  multiple pages (large/huge/super page). But again, "folio" is  the 
metadata we use to manage this chunk of memory. Just like we didn't call 
a "huge page" a "compound page" back in the days; the "compound page" 
was a way to manage the metadata assigned to a "larger chunk of memory 
covering multiple base pages" as one unit.

I once had a longer writeup about all that (including how hugetlb 
supports different huge page sizes, how freebsd calls these thing super 
pages etc).

This topic seems to pop every 6 months, likely we really should do a 
better job at documenting all that.

-- 
Cheers,

David / dhildenb