Re: [PATCH v1 2/2] mm/memory: add anonymous mTHP folios to deferred split list

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/8/26 19:52, Joanne Koong wrote:
> On Wed, Jul 8, 2026 at 12:56 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 7/7/26 22:17, Joanne Koong wrote:
>>> Unlike for PMD-sized folios, an anonymous mTHP folio doesn't get added
>>> to the deferred split list at fault or collapse time. As a result, a
>>> fully mapped mTHP folio that is mostly zero-filled doesn't get split by
>>> the deferred split shrinker when the system is under memory pressure.
>>>
>>> Add anonymous mTHP folios to the deferred split list so that if there's
>>> memory pressure, a zero-filled mTHP can be split with its zero pages
>>> remapped to the shared zero page and then reclaimed.
>>>
>>> To minimize overhead on the common order-0 fault path, the
>>> deferred_split_folio() call is guarded by an inline folio_test_large()
>>> check.
>>>
>>> Suggested-by: Usama Arif <usama.arif@linux.dev>
>>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
>>> ---
>>>  mm/memory.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index 6637c5b13c9b..441d918e3dc0 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -5259,6 +5259,8 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
>>>       folio_add_lru_vma(folio, vma);
>>>       set_ptes(vma->vm_mm, addr, pte, entry, nr_pages);
>>>       update_mmu_cache_range(NULL, vma, addr, pte, nr_pages);
>>> +     if (folio_test_large(folio))
>>> +             deferred_split_folio(folio, false);
>>>  }
>>>
>>>  static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte,
>>
>> I had a session [1] at LSF/MM about having essentially all large anon folios
>> part of the the deferred split queue.
>>
>> (1) I don't think this scales.
>>
>> (2) I suspect the shrinker should make smarter decisions of what to scan/reclaim
>> first.
>>
>> I think this needs more proper thought.
>>
>> [1]
>> https://docs.google.com/presentation/d/1RfKWCY1AMVns-WLn-QdAWbI2a-rA7fbFyh7XD1Wn5BY/edit?usp=sharing
> 
> Thanks for the link to the slides! Was there a conclusion from the
> LSF/MM discussion about the future path forward for deferred splitting
> or is that still being determined?

Sorry for the late reply. Unfortunately, it wasn't clear yet if we could
reporpuse the LRU, whereby we would just naturally benefit from the LRU cache
(soon) and only manage pages on a single list.

The concern was that we might end up scanning many items on the LRU to detect
splitting candidates.

I am not 100% sure if that is a real problem.

As raised during the last THP cabal, my gut feeling is that Johannes might have
an idea on how to improve things here.

-- 
Cheers,

David