Re: [RFC v2 0/3] Decoupling large folios dependency on THP

[Zi Yan <ziy@nvidia.com>]

On 27 Feb 2026, at 15:10, David Hildenbrand (Arm) wrote:

> On 2/27/26 16:19, Matthew Wilcox wrote:
>> On Fri, Feb 27, 2026 at 09:45:07AM +0100, David Hildenbrand (Arm) wrote:
>>> I guess it would be rather trivial to just replace
>>> add_to_page_cache_lru() by filemap_add_folio() in below code.
>>
>> In the Ottawa interpretation, that's true, but I'd prefer not to revisit
>> this code when transitioning to the New York interpretation.  This is
>> the NOMMU code after all, and the less time we spend on it, the better.
>>
>>>> So either we need to reimplement all the good stuff that folio_split()
>>>> does for us, or we need to make folio_split() available on nommu.
>>>
>>> folio splitting usually involves unmapping pages, which is rather
>>> cumbersome on nommu ;) So we'd have to think about that and the
>>> implications.
>>
>> Depending on your point of view, either everything is mapped on nommu,
>> or nothing is mapped ;-)  In any case, the folio is freshly-allocated
>> and locked, so there's no chance anybody has mapped it yet.
>>
>>> ramfs_nommu_expand_for_mapping() is all about allocating memory, not
>>> splitting something that might already in use somewhere.
>>>
>>> So I folio_split() on nommu is a bit weird in that context.
>>
>> Well, it is, but it's also exactly what we need to do -- frees folios
>> which are now entirely beyond i_size.  And it's code that's also used on
>> MMU systems, and the more code that's shared, the better.
>>
>>> When it comes to allocating memory, I would assume that it would be
>>> better (and faster!) to
>>>
>>> a) allocate a frozen high-order page
>>>
>>> b) Create the (large) folios directly on chunks of the frozen page, and
>>> add them through filemap_add_folio().
>>>
>>> We'd have a function that consumes a suitable page range and turns it
>>> into a folio (later allocates memdesc).
>>>
>>> c) Return all unused frozen bits to the page allocator
>>
>> Right, we could do that.  But that's more code and special code in the
>> nommu codebase.
>
> I guess I'd have to see the frankenstein folio_split() to judge if it is
> really better :)
>
> If it's really just about skipping the unmap+remap the end result would
> indeed be nice.

Without unmap+remap, that is just __folio_freeze_and_split_unmapped()? ;)

Best Regards,
Yan, Zi