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

[David Hildenbrand <david@redhat.com>]

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).


The filesystem tries to transparently make use of huge pages (of various 
sizes); in contrast to hugetlb, that is "transparent" in a way that 
these can be split, partially mapped, partially truncated -- just like 
for anon or shmem.

(Well, the "transparent" part was never really 100% true, but that's a 
different story)

I see more similarity with THP than with hugetlb in that sense.

In the end I don't think the terminology matters that much -- note that 
we are talking about an admin guide that resides in transhuge.rst -- as 
long as people don't confuse it with "ordinary" huge pages as in 
hugetlb. "file huge page" is rather misleading.

I'd be curious in which sense these file thingies are different than 
what we have for anon/shmem/... except that some toggles don't apply to 
them and the pagecache mostly "more transparently" makes use of them. 
(which makes them even more transparent? ;) )

-- 
Cheers,

David / dhildenb