From mboxrd@z Thu Jan 1 00:00:00 1970 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 414A8C021AA for ; Wed, 19 Feb 2025 03:50:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5B0D2801DF; Tue, 18 Feb 2025 22:50:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E3672801D7; Tue, 18 Feb 2025 22:50:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D3392801DF; Tue, 18 Feb 2025 22:50:41 -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 68FCE2801D7 for ; Tue, 18 Feb 2025 22:50:41 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EE46F160C74 for ; Wed, 19 Feb 2025 03:50:40 +0000 (UTC) X-FDA: 83135317440.29.1853B52 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf17.hostedemail.com (Postfix) with ESMTP id 2E3C34000D for ; Wed, 19 Feb 2025 03:50:38 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=U4lKHWWr; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739937039; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+mTZtKiZbGjUlF//qydZXq9I7TGlMAO3W6yY9azH3lk=; b=d+Pvoz1ZIayfMW43xtWtF9IJVoNgLfcU4K4hrcM0OZ655+Sh9zLV7iZAh28nlpIr8EuoKW wXbwRjSZDatHbt5gwHNN137Oy78w5gj85WH81aZ7NcCJeHGTpNkPYkAvBqOaeDn4A68bJZ RZ+gaFMRcA+HDzo697UglDY1YVZm6GE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739937039; a=rsa-sha256; cv=none; b=TtGIh9ciepCbO9WOkMZoaR/ng4au+gs0FNcqFQXPUwtpz7DqbCyA10HEhFj7sBUzh5FJAx XVgRXKZYJP1mbyJp1ceQL+BO93HflBUAaL7s8Iafrlztq4SRqrJ3dCf2RNRlbjvkHmufu7 wjBpDAt60oNByIf2HBjKmgLHluTdpu0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=U4lKHWWr; spf=pass (imf17.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1739937036; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+mTZtKiZbGjUlF//qydZXq9I7TGlMAO3W6yY9azH3lk=; b=U4lKHWWrRTAt+1u9ZvH2qjJeFRMKnGlVYnfmPMhDK5kXTuxn91feHvigeA+D6nGpHxqjf/ rSUq49Cow9bhTvx/R4AXLTgWmLOARvhEUGp+F1+PL/z67+cO5LQ1s5mQpjfrgT8qMbriEW t8c02WOCwhRjUi15bOEz7v/tiBWlbik= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: [PATCH V4] mm/hugetlb: wait for hugetlb folios to be freed X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <1739936804-18199-1-git-send-email-yangge1116@126.com> Date: Wed, 19 Feb 2025 11:49:57 +0800 Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, osalvador@suse.de, liuzixing@hygon.cn Content-Transfer-Encoding: quoted-printable Message-Id: <1C15A7E5-D78A-40DA-B7C5-3F49E790AC58@linux.dev> References: <1739936804-18199-1-git-send-email-yangge1116@126.com> To: yangge1116@126.com X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 2E3C34000D X-Rspamd-Server: rspam07 X-Stat-Signature: ezykf9tuo779i7hjaze45ueprgjpzeez X-HE-Tag: 1739937038-115137 X-HE-Meta: U2FsdGVkX19xb0lJFvHMacGjBAbzSpkYFWNW/58b3Ugvlu1h0Z5N/rNJdvbS/pTGh0YkGLfgvPvX8nlXvza6COmqqu/xA/v69gopfOUbNmbl05hUxZFd7951NYvKnV/g1ON+mZgcDWDuOfEVDW0GwYiy9yXW5n7xuB/1sM/xcHsc0czvl7yj6w0tx1tAGoIM+M2aoJV6qghPGWAkrr4sNWS68MRsxDxg3rQIZJ1q+X++etHG6yc0a42Q4oI0B4IPuzKWLiX+/cedGvFC9KdJX5dWcBiJ8VoPw9eNsBWfCsxydi/lNrbGFFG02e3t4HC/kDScAgvfHVmkEZ4z+dv+4Q9xmo4lHv1VUWfQGICKJksz/F73JIBcb+UzsBz4W2EJtxXxh2QsywAj2UGCZwIYZJ+xHj7lPxDh/74gMsIBVADbpyDgFSlGACfsnb+Nggl5+0fgGV6J6BPKblVoLmOGtPa1iTYMi85Pjg18HorbdBLTBcbXmQiVgb+XmnXgh6h7kz38mAGa+UDrWJ2q9bDXyeAtChXHSbSLwyfvLhRAAgS5JK8ZwdGUnDVX9U9ONEtNqBEmhRnOyyrfElYHmE72fc2QuljxP+4SwM5UiTXYLd1OAdjOGS7+74YChpQqHEg+aKcsMKLb4POuyTUcAKlJ21ifgEqzSo19OwfztxxiIjAjYEylHAC628d45Fhqn/VyCut0B4hW5ce6vP+1BcPYpiRzcAGd58TSkKb6WmPGl3ObBB9RLSfCl4Qam1TMUbL00Ow/Qm19b7L6chao7AYVvAtVQxetBpQtAHNdMl/5yHX/dyMndAJYARa1gXcRRDrm09hc5Wy9wNU4N8jc9h1w2jjlynX151mZFXkuyLFPFu1flGHI+ksBmlarBmM7j25i6PH2H/INL+Ott/wVd+s97rKmyB6Bo8H6nn2w7mWqHS/LrHTxunqbBu1jeN4oT4dofkJzdn7kJBzACgCLlPt khELyya3 m+i2QDu0KszgeM6qRbVNPoehMkIyqHV9mCH+4Up4PkiipjSORcY+FvaV3GEiwxoc1wR2eac/S3HYPg53AnMppekqsPrK1s+knf1se9/L/yDhDK2qCipn9aT0qoHBtoNGy64Blc9l9DZ6d6Nx3MjIoA5ry3bErYJJiqybYav1TrnvdMRelSe7HS/z5iK/vhulfqZMtE1SKYgDxt4RJ4D0O9ymKuYkNu30NZlcsLFKi/kj68eNJbRsdkWgtHIO2cy6HGmF6MFdIk2gnohtlbQXBGTAOFDHSG4Glf0ae X-Bogosity: Ham, tests=bogofilter, spamicity=0.000010, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > On Feb 19, 2025, at 11:46, yangge1116@126.com wrote: >=20 > From: Ge Yang >=20 > Since the introduction of commit c77c0a8ac4c52 ("mm/hugetlb: defer = freeing > of huge pages if in non-task context"), which supports deferring the > freeing of hugetlb pages, the allocation of contiguous memory through > cma_alloc() may fail probabilistically. >=20 > In the CMA allocation process, if it is found that the CMA area is = occupied > by in-use hugetlb folios, these in-use hugetlb folios need to be = migrated > to another location. When there are no available hugetlb folios in the > free hugetlb pool during the migration of in-use hugetlb folios, new = folios > are allocated from the buddy system. A temporary state is set on the = newly > allocated folio. Upon completion of the hugetlb 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(). >=20 > Here is a simplified call trace illustrating the process: > cma_alloc() > ->__alloc_contig_migrate_range() // Migrate in-use hugetlb folios > ->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 >=20 > To resolve this issue, we have implemented a function named > wait_for_freed_hugetlb_folios(). This function ensures that the = hugetlb > folios are properly released back to the buddy system after their = migration > is completed. By invoking wait_for_freed_hugetlb_folios() before = calling > PageBuddy(), we ensure that PageBuddy() will succeed. >=20 > Fixes: c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in = non-task context") > Signed-off-by: Ge Yang > Cc: Reviewed-by: Muchun Song Thanks.