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 91D0EC02198 for ; Tue, 18 Feb 2025 04:34:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 077AB2800DD; Mon, 17 Feb 2025 23:34:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F41E22800D5; Mon, 17 Feb 2025 23:34:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0ADD2800DD; Mon, 17 Feb 2025 23:34:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C0C5C2800D5 for ; Mon, 17 Feb 2025 23:34:24 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ECBD21A01FC for ; Tue, 18 Feb 2025 04:34:20 +0000 (UTC) X-FDA: 83131798680.14.4F66EB5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 4D40A1C0003 for ; Tue, 18 Feb 2025 04:34:19 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=gOU7yBLD; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739853259; 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=YykwpS5cINnwSpnrbUWcAMSU02B7J1kUJ0h2kAECvrI=; b=ugA95oB8FVHrSM2DHPBiY9sAO/PlwRua46QwsDLl2s2Aaxtf8GTIQeF2eZhTMIF6TOPw5V RORvw3wOIpB0rusTjUQ0RSiownTrUhVM8pHuEvyW7A38hGPhvgzRgkvkJmlkP/O9EJtk5T Kr7PFPh7EVBxbWY1UuIZbMDtdXMFGG4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=gOU7yBLD; spf=pass (imf21.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739853259; a=rsa-sha256; cv=none; b=QYWDajV88bG/IIkXT8RQ+zvjpY4NRFLNHhcUuRiLc5tcNCeF3rjvo8utFRC7xGTdFjYc0R n0Xt9B12QPhVbnRYZNOYCY56Mw7dh6Lpn6YAPSxAfmRGAyOJCCeRVkhY0G3ade3vqbNCSV QVL6GvOm22u7fVl+PXaNdwAhUmAIwVE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EAA3F5C55C0; Tue, 18 Feb 2025 04:33:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D7D0C4CEE2; Tue, 18 Feb 2025 04:34:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1739853257; bh=msCy2hEI5k2c9d4ihF237AdXQfcEufNHXJA14T/WN7Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gOU7yBLD5sSPSWgLpcPPEy8dEgtH68b/dwH9ijB2n/ptDrnqBVpNWhyjogjUhwOzl 5K7ogGsGAIm0mkqZA6ngOKEogRItkYriZ2VUfFz4uakxlvXLzWTrLOdwGkMpREfPvd uWLbEIU4XXK+CtN35gAh67tmTG+Fd1mdyRjKu6RE= Date: Mon, 17 Feb 2025 20:34:17 -0800 From: Andrew Morton To: yangge1116@126.com 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 Subject: Re: [PATCH V2] mm/hugetlb: wait for hugepage folios to be freed Message-Id: <20250217203417.9689a271f792a4e23da322aa@linux-foundation.org> In-Reply-To: <1739604026-2258-1-git-send-email-yangge1116@126.com> References: <1739604026-2258-1-git-send-email-yangge1116@126.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 4D40A1C0003 X-Stat-Signature: o18hagba8m94r8cwn7jq6b1iupa7b5n8 X-HE-Tag: 1739853259-957537 X-HE-Meta: U2FsdGVkX18bhuD0IBH/crd/ByKnp7MgNBSEm/ylOe3r41N/QbQI4qF6MmpCDfbpS7YYSFFF5TdNIqxcWmI+bj7Hmg0MJVZhDnQiyXQxqKhNyzWD/A6xb+thNIVymwskeH+YLFTxcFej3lW96xqZEuA8OiZS8lqD8uH4bpTXS5pBisR26C+4s5aT+NqTMJWFPR83W7IgjdDfOQ1J/PsPucwBXlC6fnzwCanPOK1Rg89Dn4tRDbB8O8pDUN92jkgQts1QM0yz1LMlDzXQ31unFHAuadZGWkiFWFh4rvG7TZCD+EfTAqkr8Z0Z+MPFXJwhIzVE2HIhzFpRBXyw0+ji89Y8aGCbZhgA0FN0DbhgNWLJgr0UQYz6AbKlDybK/3bNRBlht3DyQunBHnyyV49LlnsyYxThBHEHO8LI2eBZepApUo2woIRC0soxnt4KeWLy3wgKOajjr1AcdsG/MWj6TsgXS+0gacN2VLMx7tTfgiCobTXWvx7ycyhtN/AaetPH/zjcedqTVbrfltBfD/PoFD6jStQta8JzCQ9yUbOg+KYynNZqEbCwFN/9egf1SgRdEpStHas00Olu4K3DZcL6MmJJ/DsLKIX1lKNAnnpKfVv6I2pE8Lao7oqonRtbzKye3YRrZBxEr4pa7N7WcQ8xOTA2ebQgWLnOmyA87rVgZlcE6Px3OPg3KY8W2vzhkTAgAQt4YpbzCfB4LonaCaPTDo8yokUDrMdnFRLyc6953e3It4kmOnLO+RUWWjT0+Uqcz8t06dKpo+f4kgTDofFUTmigqbPSxyVdYmyh9qN7NeCGx5XyqjunfhbDkfKT52iPq05gc6aF1+zcaNSPRCrQ7VguidhGY4/Ise3enz3XD9UXMmQNYMiGUCqrlgiRgd5G2Amt2zfl6W2Uv5dCrKohQy7/WIk7eUL7fI8aZ5XUwQ3jYVX+cOZcRajrOSJNV7bMRBe43fbc8jsRGoRhJ14 znNsPIFj IfZ3rS9cL57Gr/3+t5Ec5KCRkN2KPttsMsxY0PMlsrKW3xlxjymbW3wk/mDqwThGil2jp8Tt1IG+hsnI1QsxHE9czzA/hiuvnjkP+4FGjmLQxCq2NhGs4lw6c6qfkEQRP1+OZpR9/9ZiszyMyPF7Z+FDGNGy00FVNVefFwNHIxLZKPDAmKczavtVgLvbOp5NT350y4QtxCAbKyoH1PXL/2pzJ/tA1zcQTKe+n5eIUytW3NvdsZmLQWQonM4Un4eExQnQl1qlD0rZ7sy4+h4mztw82T30O+/ePeDLyGSqAa4/BKYhWK6hYD+eaeQ== 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: On Sat, 15 Feb 2025 15:20:26 +0800 yangge1116@126.com wrote: > 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") Do you feel that this issue is serious enough to justify a -stable backport of the fix?