Re: [PATCH v2 2/2] mm/huge_memory: dequeue the deferred split after the split freeze
From: David Hildenbrand (Arm)
Date: Mon Sep 07 2026 - 10:38:45 EST
On 9/7/26 16:12, Kiryl Shutsemau wrote:
> On Mon, Sep 07, 2026 at 03:55:53PM +0200, David Hildenbrand (Arm) wrote:
>> On 8/31/26 11:15, Kiryl Shutsemau wrote:
>>> From: "Kiryl Shutsemau (Meta)" <kas@xxxxxxxxxx>
>>>
>>> __folio_freeze_and_split_unmapped() takes the deferred split list_lru lock
>>> across the freeze. It is only there to stop deferred_split_scan() from
>>> touching the folio under split.
>>>
>>> With deferred_split_isolate() fixed, the workaround can be dropped.
>>>
>>> Unqueue the folio after folio_ref_freeze(), the way
>>> __folio_migrate_mapping() does: folio_unqueue_deferred_split() needs a
>>> zero refcount and a memcg still set, and both hold there.
>>>
>>> If the split is called from deferred_split_scan(), the unqueue is a
>>> no-op -- the folio is already removed from the list. But
>>> PG_partially_mapped is still set, so it has to be cleared here or
>>> MTHP_STAT_NR_ANON_PARTIALLY_MAPPED never comes back down.
>>>
>>> Assisted-by: Claude-Code:claude-opus-5
>>> Signed-off-by: Kiryl Shutsemau (Meta) <kas@xxxxxxxxxx>
>>> Reviewed-by: Zi Yan <ziy@xxxxxxxxxx>
>>> Reviewed-by: Johannes Weiner <hannes@xxxxxxxxxxx>
>>> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>>> ---
>>> mm/huge_memory.c | 44 +++++++++++++-------------------------------
>>> 1 file changed, 13 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 6281ed993243..c84e8cbc986d 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3931,41 +3931,27 @@ static int __folio_freeze_and_split_unmapped(struct folio *folio, unsigned int n
>>> struct folio *end_folio = folio_next(folio);
>>> struct folio *new_folio, *next;
>>> int old_order = folio_order(folio);
>>> - struct list_lru_one *lru;
>>> - bool dequeue_deferred;
>>> int ret = 0;
>>>
>>> VM_WARN_ON_ONCE(!mapping && end);
>>> - /*
>>> - * If this folio can be on the deferred split queue, lock out
>>> - * the shrinker before freezing the ref. If the shrinker sees
>>> - * a 0-ref folio, it assumes it beat folio_put() to the list
>>> - * lock and must clean up the LRU state - the same dequeue we
>>> - * will do below as part of the split.
>>> - */
>>> - dequeue_deferred = folio_test_anon(folio) && old_order > 1;
>>> - if (dequeue_deferred) {
>>> - struct mem_cgroup *memcg;
>>>
>>> - rcu_read_lock();
>>> - memcg = folio_memcg(folio);
>>> - lru = list_lru_lock(&deferred_split_lru,
>>> - folio_nid(folio), &memcg);
>>> - }
>>
>> Nice cleanup.
>>
>>> if (folio_ref_freeze(folio, folio_cache_ref_count(folio) + 1)) {
>>> struct swap_cluster_info *ci = NULL;
>>> struct lruvec *lruvec;
>>>
>>> - if (dequeue_deferred) {
>>> - __list_lru_del(&deferred_split_lru, lru,
>>> - &folio->_deferred_list, folio_nid(folio));
>>> - if (folio_test_partially_mapped(folio)) {
>>> - folio_clear_partially_mapped(folio);
>>> - mod_mthp_stat(old_order,
>>> - MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, -1);
>>> - }
>>> - list_lru_unlock(lru);
>>> - rcu_read_unlock();
>>> + /* Take off the deferred split queue while frozen and memcg set */
>>> + folio_unqueue_deferred_split(folio);
>>> +
>>> + /*
>>> + * deferred_split_scan() takes the folio off the queue before it
>>> + * splits it, so the unqueue above finds an empty list and
>>> + * leaves PG_partially_mapped set.
>>> + * Clear it here: the flag does not survive the split.
>>> + */
>>> + if (folio_test_partially_mapped(folio)) {
>>> + folio_clear_partially_mapped(folio);
>>> + mod_mthp_stat(old_order,
>>> + MTHP_STAT_NR_ANON_PARTIALLY_MAPPED, -1);
>>> }
>>
>> In general,
>>
>> Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>>
>> But I do wonder whether this sequence (that also
>> __folio_unqueue_deferred_split()) performs would deserve a small local helper in
>> mm/huge_memory.c
>>
>> Could be done as a separate cleanup.
>
> Just to be sure, do you want a helper like this:
Something like that. I'd probably call it folio_reset_partially_mapped()
--
Cheers,
David