From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D31C33B14AA for ; Wed, 19 Aug 2026 09:05:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787130354; cv=none; b=hyl46qZz5IZf3ai0xyVSXerjNzKq8DszEYYr/EilAzneIilB3MWGXdgmrIKDIL7gVw1I7fpuU7oYoop7HCvwKOk4ZkJTfmJOS0cYbkgtPMNnspvbiB/RoN42zjp763YWxYru+o5N215Xeaa+r5i2Jd7vQ5RFWW+sEovcrU3c3iE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787130354; c=relaxed/simple; bh=Fi/Fa2WdEFb14ZrVyq8EKDD5uBrQBjEZn9axVt+uUww=; h=Subject:To:CC:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=oZYf7BoTpX1NLws2ONCXLk4li5NIoMZZUhem50Brusw8BsKW5fDtwcqjke724heZKoooLMAuPJXUyFn7r72J2t1vRN4yQDlElb59So5F+rFGSYlcYKJS/z1fPtcmcdZaYZ1Eg9sKIWCUdBAnB9DCVIr01HlOFLkw/WLTDq8whMA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=eO7szIPe; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="eO7szIPe" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=GR0Iu6H6PDazI16+rVYPbxLdITggVxZY8J6rOkCftR8=; b=eO7szIPeS+RuMp5eFxXT4g5QYQfc7ul8QUKX7mF8bmrTOZYsOcE5zofFJSOgD5x0NxVLmtqjZ MbA36pR7X7zBCG/4J9k6p+oWcdHA+nXG92jj7aNnLwby509v0toNtU52WDN4gFqPZmrb5SLLaqo WuQfhIUvFZyJZx2TqdRzdFc= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4hQ0kt5w1nz1prQt; Wed, 19 Aug 2026 16:55:02 +0800 (CST) Received: from dggemv706-chm.china.huawei.com (unknown [10.3.19.33]) by mail.maildlp.com (Postfix) with ESMTPS id 26FD24056D; Wed, 19 Aug 2026 17:05:46 +0800 (CST) Received: from kwepemq500010.china.huawei.com (7.202.194.235) by dggemv706-chm.china.huawei.com (10.3.19.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 19 Aug 2026 17:05:45 +0800 Received: from [10.173.124.160] (10.173.124.160) by kwepemq500010.china.huawei.com (7.202.194.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 19 Aug 2026 17:05:44 +0800 Subject: Re: [PATCH v2 7/7] mm/rmap: batch the unmap of large folios in try_to_migrate_one() To: Lance Yang CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <860941c2-287f-f88f-920c-6d99e2cd4483@huawei.com> <20260818092032.47670-1-lance.yang@linux.dev> From: Miaohe Lin Message-ID: Date: Wed, 19 Aug 2026 17:05:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20260818092032.47670-1-lance.yang@linux.dev> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemq500010.china.huawei.com (7.202.194.235) 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 >>>> --- >>>> 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. .