From patchwork Sat Feb 15 07:20:26 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ge Yang X-Patchwork-Id: 13975964 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5EE7C021A0 for ; Sat, 15 Feb 2025 07:20:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1681F280001; Sat, 15 Feb 2025 02:20:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EF636B008A; Sat, 15 Feb 2025 02:20:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAA45280001; Sat, 15 Feb 2025 02:20:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C7FC36B0083 for ; Sat, 15 Feb 2025 02:20:38 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7B60F161736 for ; Sat, 15 Feb 2025 07:20:38 +0000 (UTC) X-FDA: 83121331356.26.8F8DD83 Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.9]) by imf16.hostedemail.com (Postfix) with ESMTP id 6E6F3180002 for ; Sat, 15 Feb 2025 07:20:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=VelXm3zB; spf=pass (imf16.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.9 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739604037; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references:dkim-signature; bh=agHQ3lenbLOgIS9g7bcB70WfrVWcB0GiCF7MKu9qzgM=; b=q8IpCdJKfqB+KA4sbhPnYk2CM2tJ33WTdPxrk3E1cobj/Y5PVRauOHw896iANOvNQtfzVm 7Y5y6Y23ED/cF5Zs58JwbzQSWTxkKkJiri6DhlLRhKJKd919qPF9XM4BsBG1DE0hecst2H dim56OamoxMPsYdUD79iJslQa7IwAos= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=VelXm3zB; spf=pass (imf16.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.9 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739604037; a=rsa-sha256; cv=none; b=bWjngvB7LCwne9Zx47NYTkg/4BLD1eGDOU39+Fr/HEthhhf947fMSpEfEQlqw78ch9CVs7 rHWMo+2mOFJ0o3kj+QPEPvoB1aI3wKKg8zkx5v0Qtgc0kOOg4HTr6hW8DLTZ2AkjBW+nSb Lt7IKlaterBav9WtcsNqivLmsDJkk0I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=From:Subject:Date:Message-Id; bh=agHQ3lenbLOgIS9g7b cB70WfrVWcB0GiCF7MKu9qzgM=; b=VelXm3zB73ANjuuDCGmHZwdJ23/NOSMyZf cFdAa9gYjh2sG5Ph/3LMmCzBZUdfmjtgA2pVWnzzaIcYzfZG1IhSEmVX2xGCgwkI mjggBmt/wDI9GI4Sz6sT30uNS/SdCDrpBZlhC2rw3oGH4Sn3M/lIBu5baQe0JBzL 4tRd5HciM= Received: from hg-OptiPlex-7040.hygon.cn (unknown []) by gzga-smtp-mtada-g0-0 (Coremail) with SMTP id _____wC3j9M8QLBnZ7P7Aw--.29501S2; Sat, 15 Feb 2025 15:20:29 +0800 (CST) From: yangge1116@126.com To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, muchun.song@linux.dev, osalvador@suse.de, liuzixing@hygon.cn, Ge Yang Subject: [PATCH V2] mm/hugetlb: wait for hugepage folios to be freed Date: Sat, 15 Feb 2025 15:20:26 +0800 Message-Id: <1739604026-2258-1-git-send-email-yangge1116@126.com> X-Mailer: git-send-email 2.7.4 X-CM-TRANSID: _____wC3j9M8QLBnZ7P7Aw--.29501S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxXryrCFy8Xr45tw4UKr1UAwb_yoWrZF1xpF yUKr43GFWDJ3sakrnrZws8Ar1Ik395ZFW2krWIqw45Z3ZxJa4DKFy2vw1qq3y5ZrWkCFWx ZrWjvrWDuF1UA3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zRoGQDUUUUU= X-Originating-IP: [112.64.138.194] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbifgb0G2ewM0J3AAAAsG X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6E6F3180002 X-Stat-Signature: wrq3bjcb4b5boq64ysdwd5rfjz6js7w1 X-Rspam-User: X-HE-Tag: 1739604035-744742 X-HE-Meta: U2FsdGVkX18ye/t1SZeXK9eO9myo0yBd59GTKbgtx7SbLg60pIM0RrTyF/ogaQ4py+kGc0Ld1In2gSbA73y2a7butHG6eU4hKFkaacCHcqHtz5vbHPQi8r8Yv3Dbh0neZJSV97BhTtA1lUX3IQQMmzzfMaNdjA/wtBSyjPCozrwjG9XIcdgCqzVA+9Le0r7CshLSwgVzODF1wVR5w9vto1ZV3ABp+dF7CgMjTuW/anjxmx18WaeYgPSgKdtkdL2ppABtSdkPemhPbHYyF7YiX/5SaVsOU9QjO+XON9xFtqa1FF5jf6K8XOXIpQeC40gqu+glguRffWSrfihVXp8wOBjCU6VAYTE7lVXqYbejYGC4nqZLb6Qp4+wl8HnFgvHGNQz2pv+wzFhy4vFwfEUv99Ey0DgGckHuSm2Esz52NtZhun71r0GdKOMP6RA0+z/vgoo0YHoJo4T389E9Zo3WmofkxsjneDYZGn1StHub4To7vL6YdqapTOgEndNioJT7rM0TNrZ5LSDkxVHLkrie0vrLT8nAM1WUfz5GmwNyKJoSHImS1Tmg8qVI/w6tJHdnHcJ/7h4s6bI1M0mIf0DHQz4iQ8UueJUg7fHeeB89EKkUF5BekOWE+pbYm1/sWvVERKuzgBKQP1YDSVeq42FhT0SMcoxJAIWlWWSoXtlhI4AFvNtrXqD2Xfz0MltdhH1KgZetcKa6oIC6Y78GkC5sQSXDGocOJbt4qqbnwXwQkzTk0f3r+4XucHwIthtYWYoaH9LsZ+OX6RnMQ2vkXseh5Piw1eEZxPAAjFvvA5QtKkuoO09dmIYiNg4bjfAXXW/d2eAemksKkj+x4lPVipdbtxnsl3BLl+G1/O3rgaMAkAMGLB/XXknlaP9537vV4Yz8/527ws/cRNr9FFTeJRxFVUZ+9z4MmepjEmM1dUUE7LxhdSpCBUktSJUi+N4bLqi6onf9rMgh6BiVIFMgr3/ VsW121B5 BmW8s/Hr1Cpn8GFfDqdmh0SL9aZ6S2lRHKYY3Ih8qejZQO/vKj8mS8cPLvURlADJO7EAPRfAowRZFsKyxdJMMG3BvjWbTXCCbbAyIen/rpFFau+ynp2IkaxqSGGtRQ3wybSS4jm8epTHIjstks0mZMDFqP834FUwRYijW5T4J0XbSkMi+++Le4ZFXWqRHePvPeNVwHhYpBaW/CnTOl2nvOM/ieMVuxoMFBQ9H85xcnJ91RUuXI4BOJkbFba6GAlwOODjh5tEfC2orPnWpf9Y7CdJhhQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Ge Yang Since the introduction of commit b65d4adbc0f0 ("mm: hugetlb: defer freeing of HugeTLB pages"), which supports deferring the freeing of HugeTLB pages, the allocation of contiguous memory through cma_alloc() may fail probabilistically. In the CMA allocation process, if it is found that the CMA area is occupied by in-use hugepage folios, these in-use hugepage folios need to be migrated to another location. When there are no available hugepage folios in the free HugeTLB pool during the migration of in-use HugeTLB pages, new folios are allocated from the buddy system. A temporary state is set on the newly allocated folio. Upon completion of the hugepage folio migration, the temporary state is transferred from the new folios to the old folios. Normally, when the old folios with the temporary state are freed, it is directly released back to the buddy system. However, due to the deferred freeing of HugeTLB pages, the PageBuddy() check fails, ultimately leading to the failure of cma_alloc(). Here is a simplified call trace illustrating the process: cma_alloc() ->__alloc_contig_migrate_range() // Migrate in-use hugepage ->unmap_and_move_huge_page() ->folio_putback_hugetlb() // Free old folios ->test_pages_isolated() ->__test_page_isolated_in_pageblock() ->PageBuddy(page) // Check if the page is in buddy To resolve this issue, we have implemented a function named wait_for_hugepage_folios_freed(). This function ensures that the hugepage folios are properly released back to the buddy system after their migration is completed. By invoking wait_for_hugepage_folios_freed() before calling PageBuddy(), we ensure that PageBuddy() will succeed. Fixes: b65d4adbc0f0 ("mm: hugetlb: defer freeing of HugeTLB pages") Signed-off-by: Ge Yang --- V2: - flush all folios at once suggested by David include/linux/hugetlb.h | 5 +++++ mm/hugetlb.c | 8 ++++++++ mm/page_isolation.c | 10 ++++++++++ 3 files changed, 23 insertions(+) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 6c6546b..04708b0 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -697,6 +697,7 @@ bool hugetlb_bootmem_page_zones_valid(int nid, struct huge_bootmem_page *m); int isolate_or_dissolve_huge_page(struct page *page, struct list_head *list); int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn); +void wait_for_hugepage_folios_freed(void); struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, unsigned long addr, bool cow_from_owner); struct folio *alloc_hugetlb_folio_nodemask(struct hstate *h, int preferred_nid, @@ -1092,6 +1093,10 @@ static inline int replace_free_hugepage_folios(unsigned long start_pfn, return 0; } +static inline void wait_for_hugepage_folios_freed(void) +{ +} + static inline struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, unsigned long addr, bool cow_from_owner) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 30bc34d..36dd3e4 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2955,6 +2955,14 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn) return ret; } +void wait_for_hugepage_folios_freed(void) +{ + struct hstate *h; + + for_each_hstate(h) + flush_free_hpage_work(h); +} + typedef enum { /* * For either 0/1: we checked the per-vma resv map, and one resv diff --git a/mm/page_isolation.c b/mm/page_isolation.c index 8ed53ee0..f56cf02 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -615,6 +615,16 @@ int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn, int ret; /* + * Due to the deferred freeing of HugeTLB folios, the hugepage folios may + * not immediately release to the buddy system. This can cause PageBuddy() + * to fail in __test_page_isolated_in_pageblock(). To ensure that the + * hugepage folios are properly released back to the buddy system, we + * invoke the wait_for_hugepage_folios_freed() function to wait for the + * release to complete. + */ + wait_for_hugepage_folios_freed(); + + /* * Note: pageblock_nr_pages != MAX_PAGE_ORDER. Then, chunks of free * pages are not aligned to pageblock_nr_pages. * Then we just check migratetype first.