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 5DBD3C02198 for ; Tue, 18 Feb 2025 09:54:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5E8C2800D2; Tue, 18 Feb 2025 04:54:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E0D712800D1; Tue, 18 Feb 2025 04:54:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD4E32800D2; Tue, 18 Feb 2025 04:54:33 -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 B20E52800D1 for ; Tue, 18 Feb 2025 04:54:33 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5E8E6140BC9 for ; Tue, 18 Feb 2025 09:54:33 +0000 (UTC) X-FDA: 83132605626.08.8601881 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.7]) by imf03.hostedemail.com (Postfix) with ESMTP id 5662C2000E for ; Tue, 18 Feb 2025 09:54:29 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=X3SCfEdK; spf=pass (imf03.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.7 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=1739872471; 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=kJ6LrcISp0pEkzAuJFI1bnjTPAQybpsNr4hJemU74dE=; b=QSmREi36yB6Aua2q5PoHbjYGUvdxuQoZT2Nv7+NGiflITelGupawc7LdCwUpMx0//wRQVn 7wCuZkzrn41MaW/ftFVPOWGovbKiie/Cgj590EHy2KS+S799mDLuJ5cDI4YQnQ8a7ObrLC tFtUiXwE8CSpr8VVntFBUOmP0ixP39k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739872471; a=rsa-sha256; cv=none; b=hBY+teC6lKffWQbNGmU8K5nAffnK529BkUkSxWMI89pVmIUfJTK/4XZ8hsHitBTczEbEaU 0gTzgYM2qhi/qVvOdbalh23JH3cIw/tEyCAfUHoQIPCMdd7KP/OlacpO1dpADR8qJaVyHF lm/Qk1esFrbniOhFy7xCpLdJE55KNCM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=X3SCfEdK; spf=pass (imf03.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.7 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:From: Content-Type; bh=kJ6LrcISp0pEkzAuJFI1bnjTPAQybpsNr4hJemU74dE=; b=X3SCfEdKvPHkA7JUkBDmTbJYQRPt9fSlp1zFsQHUqkYwt/cZV9znesLsBdpUC6 lrfcQP+Xs8swe3MqwUYKbp3h5sCIjyYHk84V9hhbLIzu+tH+EF+t/A83X0anSXra E6ZJ6BA3LjYDwWH5D+P63WP0lawRoHrNpgGMD57KeYX/g= Received: from [172.19.20.199] (unknown []) by gzga-smtp-mtada-g1-1 (Coremail) with SMTP id _____wDn1zHQWLRnR_lCBA--.40367S2; Tue, 18 Feb 2025 17:54:25 +0800 (CST) Message-ID: Date: Tue, 18 Feb 2025 17:54:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/hugetlb: wait for hugepage folios to be freed To: David Hildenbrand , akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, baolin.wang@linux.alibaba.com, muchun.song@linux.dev, osalvador@suse.de, liuzixing@hygon.cn References: <1739514729-21265-1-git-send-email-yangge1116@126.com> <37363b17-88b0-4ccc-a115-8c9f1d83a1b5@redhat.com> <2d0b01c5-a736-41d5-a0f7-db0da065d049@redhat.com> <406c6713-356b-4acf-bcd0-e5a6c1e9adcf@126.com> <048ca765-bf44-46ab-87d4-328dc0979159@redhat.com> From: Ge Yang In-Reply-To: <048ca765-bf44-46ab-87d4-328dc0979159@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wDn1zHQWLRnR_lCBA--.40367S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxGr1xWF1ktr43ZrWfZw4Utwb_yoW5trWUpr W3Ga17KrWDJrySyrnFqwn09r10yrWUXrW8Wr1Yqr17Crs0yr17KF42yw15uFW5Zr10kF40 qr4YvwnrZF1UA3JanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUo7tUUUUU= X-Originating-IP: [112.64.138.194] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbifgP3G2e0TMW1YgAAsc X-Rspam-User: X-Rspamd-Queue-Id: 5662C2000E X-Rspamd-Server: rspam07 X-Stat-Signature: h875i734popugayg85k677dyb4nnnyni X-HE-Tag: 1739872469-693571 X-HE-Meta: U2FsdGVkX198dde8gNUoom4DKpgjAyluleAkrXDtGxn1vdbtmLqzTsDkYo8p2wAlDiGXlRyLGS7/RoDqqAzOX7B/QYXgppRoXzSMk/NsdPAsM64Ix/sMfyzXriCY/m/a8/N1BIcjHohppmGGVU4vN2oKk/ignbSQ+XSWoos+SKXzTKl/wlCXvYmd/3qXmyXpn07fQiVJUBCxahy4uTI+mJcls2rU39hsFho2iMjKD+OQivz1qcaKm1kHItFvNLNMjXYknDQYlaFiIZtfLX+prCbPJowCnQB1jQBPFgaGqDHoHEEjDSGF33Ci6qaSwFBgo6ADc9zn042t8Smo03Ga16kAT/exyxWyByYCIAzX4kZJG6LD2fiTVbCHNdxFnLkiytZ3YF6cYdkvbFWvPeLX37edNfQc1tU7EYNjEOjsFppdm7oQ9m4NMgJhDAr5BxTglvTymcnBvcgR5otv/37jzhhWdynGpw4+PsYsWMjc/LWnI+ici63eAuMCxoDpxKGTNX43Nnh7rZwNdGamPwd+k+4zHn6Hitn9YmknPvCXcq3b8xWZ/GHmIJlT5d7ljZaH2xcA6ObgZmErEUVsbd3WpigaFQeq6iBbjxLH16uCWBNnSUr1LpgoKSCiNQTZ3nOegVI+NP1hOWEH6eGNznrqwbbA5nKWE1dB2uHigD4ucpOWmaLytJuEwFe0DBe0jAbmdvVM7V7d00Fy90+ZoApXn/Bu4yDq3wiNYFqVbuf3qYY0kt1DyC1JxDX0Y9rpr4Tjl6kydIpmPjc3WGU2PaRDR7prPF2iO0kibXvfwtINo0c0UEaYTBNuJirb5yFxTPumUZmH8xnuzJzTMJ/tqZg1BAS8xVh0sGUK3nlTVaAO3B2jWGo7U9EaH00JHisUKJnvOIZ3A+lh9l4qgXR1+qOrBsAKJ451bBPZPULASfPQxhc0j/K/KgTUUkoUnsO20rbQ7yI/REF670s2gmdSj3v HHfZrZ0F 7XWMmVJO7zoQWh3CKe3g5KQ78Fl7SUpCLhQGuWnRYj4VUyZ8M9Y9KLA2txp596q218dHL/R+Rz8ZYEhT+Xp7eq9suBayuPStqEm1U5Mt3a2/oLYG5ETM7YWi+Wj0msV8US/2em0qWQdQpVUv+2yx50LiC9l4Bynni/syN0Ld6JZwHdOnMavyMHnku6VrO9zRcy8QQH+g5sJW92CwMVdS8PvcuRt3YuoNPkKlbAl48CI7cnoh/tdMl8zXlULjzrQy4cYuRN9BKlYsh6ONjJoQk16n1uvqZkvye7EoubHBv/jPCiu0f5TzsrH9ooX52B4ov65RsxKo0G1yLYpRaurx/ICEWvcC9zlFfLhDyvsi6+gv8EFS4X5FAkGIoc4ZWew3FnqqSoD/vQVEI0+g= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 在 2025/2/18 17:41, David Hildenbrand 写道: > On 18.02.25 10:22, Ge Yang wrote: >> >> >> 在 2025/2/18 16:55, David Hildenbrand 写道: >>> On 15.02.25 06:50, Ge Yang wrote: >>>> >>>> >>>> 在 2025/2/14 16:08, David Hildenbrand 写道: >>>>> On 14.02.25 07:32, 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() following >>>>>> the >>>>>> migration process, we guarantee that when test_pages_isolated() is >>>>>> executed, it will successfully pass. >>>>> >>>>> Okay, so after every successful migration -> put of src, we wait >>>>> for the >>>>> src to actually get freed. >>>>> >>>>> When migrating multiple hugetlb folios, we'd wait once per folio. >>>>> >>>>> It reminds me a bit about pcp caches, where folios are !buddy until >>>>> the >>>>> pcp was drained. >>>>> >>>> It seems that we only track unmovable, reclaimable, and movable >>>> pages on >>>> the pcp lists. For specific details, please refer to the >>>> free_frozen_pages() function. >>> >>> It reminded me about PCP caches, because we effectively also have to >>> wait for some stuck folios to properly get freed to the buddy. >>> >> It seems that when an isolated page is freed, it won't be placed back >> into the PCP caches. > > I recall there are cases when the page was in the pcp before the > isolation started, which is why we drain the pcp at some point (IIRC). > Yes, indeed, drain_all_pages(cc.zone) is currently executed before __alloc_contig_migrate_range().