From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (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 47C5D8C0B for ; Wed, 19 Feb 2025 03:50:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739937051; cv=none; b=kA1q8XjAKXUJlTCA1rpLGdh3VCPUivYCB4AinCGbYusp9jDDMt+tkllSHhpznupN8QvOW/cCx89MQfLP///HS0fYvcFTvBcoQJ1+FNJuozqapSnqyunpv02/ZpkGRlacphNmIiGlji+Zlw/g+jQc/+kUX86Ycu64yxKIpsYEiSo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739937051; c=relaxed/simple; bh=J8+NPZwTw8bslS0dqKvL9vPv+Cqwy7Gi7z+qq6XDXAU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=hvls6w2SYos9kBDmzlSYM4gDDAEF4CYC07V7KeisljxmRRw8pSzrX1DcG4fbVdE1u3QhSqzsAfZWb799UOmLkz5b25xfcMlRkytlDCBNe8sq4YocuWDh97BF37aa5hfTeLuZ1iGL37fUKZ4ZfQ9ZrBBHyOIRKqDHOpnOYK1bZ0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=U4lKHWWr; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="U4lKHWWr" 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= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 > 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.