Re: [PATCH v2 7/7] mm/rmap: batch the unmap of large folios in try_to_migrate_one()

[Miaohe Lin <linmiaohe@huawei.com>]

On 2026/8/18 17:20, Lance Yang wrote:
> 
> On Tue, Aug 18, 2026 at 04:55:06PM +0800, Miaohe Lin wrote:
>> On 2026/8/17 17:14, Lance Yang wrote:
>>> +Cc Miaohe
>>>
>>> On Thu, Aug 13, 2026 at 04:23:18AM +0000, Shivank Garg wrote:
>>>> try_to_migrate_one() converts present PTEs to migration entries one at a
>>>> time. For a PTE-mapped large folio, this repeat calls to ptep clear+flush,
>>>> the migration entry build and set, folio_remove_rmap_pte() and folio_put(),
>>>> each re-entering page_vma_mapped_walk() once per base page (256 times for
>>>> 1M folio).
>>>>
>>>> Mirror try_to_unmap_one() to introduce folio_migrate_pte_batch() to detect
>>>> eligible batch for PTEs mapping conseuctive subpages of a large folios,
>>>> and convert the whole batch in one shot using the batched helpers.
>>>>
>>>> A side-effect of this change is trace_set_migration_pte() will record
>>>> one event per batched run instead of earlier behavior of one per base page.
>>>>
>>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>>> ---
>>>> mm/rmap.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++----------------
>>>> 1 file changed, 86 insertions(+), 29 deletions(-)
>>>>
>>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>>> index 35752a70f3a0..63b885c0b7ef 100644
>>>> --- a/mm/rmap.c
>>>> +++ b/mm/rmap.c
>>>> @@ -2675,6 +2675,44 @@ static bool try_to_migrate_hugetlb_one(struct folio *folio,
>>>> 	return ret;
>>>> }
>>>>
>>>> +static inline unsigned int folio_migrate_pte_batch(struct folio *folio,
>>>> +		struct page_vma_mapped_walk *pvmw, pte_t pte,
>>>> +		struct page *subpage, bool anon_exclusive)
>>>> +{
>>>> +	unsigned long end_addr, addr = pvmw->address;
>>>> +	struct vm_area_struct *vma = pvmw->vma;
>>>> +	unsigned int max_nr, nr;
>>>> +
>>>> +#ifdef __HAVE_ARCH_UNMAP_ONE
>>>> +	/* Cannot batch unmap if arch_unmap_one() is defined. */
>>>> +	return 1;
>>>> +#endif
>>>> +
>>>> +	if (!folio_test_large(folio))
>>>> +		return 1;
>>>> +	if (folio_is_zone_device(folio) || folio_test_has_hwpoisoned(folio))
>>>> +		return 1;
>>>> +	if (pte_unused(pte))
>>>> +		return 1;
>>>> +
>>>> +	/* We may only batch within a single VMA and a single page table. */
>>>> +	end_addr = pmd_addr_end(addr, vma->vm_end);
>>>> +	max_nr = (end_addr - addr) >> PAGE_SHIFT;
>>>
>>> Hmm ... can this still batch over a poisoned tail page?
>>>
>>> memory_failure() sets PageHWPoison() before taking folio lock, but
>>> cannot set PG_has_hwpoisoned until it acquires and releases that lock.
>>>
>>> So tail page can already be poisoned while folio_test_has_hwpoisoned()
>>> still returns false ... no?
>>
>> When memory error hits thp pages, memory_failure() first set PG_has_hwpoisoned and
>> then tries to split thp pages. And try_to_migrate() will be called to set migration
>> entries for anon pages. Does folio_migrate_pte_batch() work on this case? If so, the
>> folio_test_has_hwpoisoned() check above could catch the bad pages?
>>
>> Or do you worry about the scene that meory error hits a thp while it's under migration?
> 
> Yeah, latter case is exactly what I meant.
> 
> try_to_migrate() is called with folio lock held. If migration already
> owns the lock, memory_failure() can set PageHWPoison() on a tail page and
> then block in folio_lock(), before reaching folio_set_has_hwpoisoned().
> try_to_migrate_one() may meanwhile start from a healthy subpage, see
> PageHWPoison(subpage) clear and PG_has_hwpoisoned still clear, then batch
> across poisoned tail and install a normal migration entry for it.

Even if try_to_migrate() batches across poisoned tail and install a normal migration entry
for it, memory_failure() will call try_to_split_thp_page() and unmap_poisoned_folio() to
unmap the poisoned tail. So it seems work. Or am I miss something?

Thanks.
.