All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Wei Yang <richard.weiyang@gmail.com>,
	Usama Arif <usama.arif@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	npache@redhat.com, ziy@nvidia.com, willy@infradead.org,
	linux-mm@kvack.org, matthew.brost@intel.com,
	joshua.hahnjy@gmail.com, hannes@cmpxchg.org, rakie.kim@sk.com,
	byungchul@sk.com, gourry@gourry.net,
	ying.huang@linux.alibaba.com, apopple@nvidia.com,
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v2] mm: migrate: requeue destination folio on deferred split queue
Date: Mon, 22 Jun 2026 13:43:31 +0000	[thread overview]
Message-ID: <20260622134331.xvbpu6edwml65myp@master> (raw)
In-Reply-To: <f820a74a-ee28-4888-a5ac-e1c4de8c0202@kernel.org>

On Mon, Jun 22, 2026 at 11:16:39AM +0200, David Hildenbrand (Arm) wrote:
>On 6/20/26 09:27, Wei Yang wrote:
>> On Tue, Mar 10, 2026 at 03:54:19AM -0700, Usama Arif wrote:
>>> During folio migration, __folio_migrate_mapping() removes the source
>>> folio from the deferred split queue, but the destination folio is never
>>> re-queued.  This causes underutilized THPs to escape the shrinker after
>>> NUMA migration, since they silently drop off the deferred split list.
>>>
>>> Fix this by recording whether the source folio was on the deferred split
>>> queue and its partially mapped state before move_to_new_folio() unqueues
>>> it, and re-queuing the destination folio after a successful migration if
>>> it was.
>>>
>>> By the time migrate_folio_move() runs, partially mapped folios without a
>>> pin have already been split by migrate_pages_batch().  So only two cases
>>> remain on the deferred list at this point:
>>>  1. Partially mapped folios with a pin (split failed).
>>>  2. Fully mapped but potentially underused folios.
>>> The recorded partially_mapped state is forwarded to deferred_split_folio()
>>> so that the destination folio is correctly re-queued in both cases.
>>>
>>> Reported-by: Johannes Weiner <hannes@cmpxchg.org>
>>> Fixes: dafff3f4c850 ("mm: split underused THPs")
>>> Signed-off-by: Usama Arif <usama.arif@linux.dev>
>>> ---
>>> v1 -> v2:
>>> - record whether source folio was on the deferred split queue before
>>>  move_to_folio() (David)
>>> - record partially mapped state and update commit message (Zi)
>>> ---
>>> mm/migrate.c | 17 +++++++++++++++++
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>> index ece77ccb2ec0..61013d258eb4 100644
>>> --- a/mm/migrate.c
>>> +++ b/mm/migrate.c
>>> @@ -1360,6 +1360,8 @@ static int migrate_folio_move(free_folio_t put_new_folio, unsigned long private,
>>> 	int rc;
>>> 	int old_page_state = 0;
>>> 	struct anon_vma *anon_vma = NULL;
>>> +	bool src_deferred_split = false;
>>> +	bool src_partially_mapped = false;
>>> 	struct list_head *prev;
>>>
>>> 	__migrate_folio_extract(dst, &old_page_state, &anon_vma);
>>> @@ -1373,6 +1375,12 @@ static int migrate_folio_move(free_folio_t put_new_folio, unsigned long private,
>>> 		goto out_unlock_both;
>>> 	}
>>>
>>> +	if (folio_test_large(src) && folio_test_large_rmappable(src) &&
>>> +	    !data_race(list_empty(&src->_deferred_list))) {
>>> +		src_deferred_split = true;
>>> +		src_partially_mapped = folio_test_partially_mapped(src);
>>> +	}
>> 
>> Hi, Usama
>> 
>> I am afraid there maybe a race between migration and defer_split.
>> 
>>                 A                              B
>>   migrate_pages_batch                   deferred_split_scan
>>     migrate_folio_unmap                   list_del_init(&folio->_deferred_list)
>>       folio_lock/folio_trylock
>> 
>>     migrate_folios_move
>>       migrate_folio_move
>>         list_empty(&src->_deferred_list)
>>                                           folio_trylock()
>>                                           requeue:
>> 
>> In case list_empty() check happens after folio removed from defer_list but
>> before requeued, we will miss this folio.
>
>deferred_split_isolate() would grab a reference through folio_try_get().
>
>How can we migrate a folio with a raised refcount?
>

Thanks, I missed expected_refcount check in __migrate_folio().

>-- 
>Cheers,
>
>David

-- 
Wei Yang
Help you, Help me


  reply	other threads:[~2026-06-22 13:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-10 10:54 [PATCH v2] mm: migrate: requeue destination folio on deferred split queue Usama Arif
2026-03-10 16:52 ` Zi Yan
2026-03-11  9:23 ` David Hildenbrand (Arm)
2026-03-11 13:25   ` Usama Arif
2026-03-12  3:18 ` Wei Yang
2026-03-12  8:26   ` David Hildenbrand (Arm)
2026-06-20  7:27 ` Wei Yang
2026-06-22  9:16   ` David Hildenbrand (Arm)
2026-06-22 13:43     ` Wei Yang [this message]
2026-06-22 16:44       ` Usama Arif

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260622134331.xvbpu6edwml65myp@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=npache@redhat.com \
    --cc=rakie.kim@sk.com \
    --cc=usama.arif@linux.dev \
    --cc=willy@infradead.org \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.