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 57734C021AA for ; Wed, 19 Feb 2025 03:40:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E71AD2801DD; Tue, 18 Feb 2025 22:40:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD27C2801D7; Tue, 18 Feb 2025 22:40:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C74272801DD; Tue, 18 Feb 2025 22:40:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A6C712801D7 for ; Tue, 18 Feb 2025 22:40:10 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2A5FF1A0D46 for ; Wed, 19 Feb 2025 03:40:10 +0000 (UTC) X-FDA: 83135290980.05.BE8D6D7 Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.8]) by imf30.hostedemail.com (Postfix) with ESMTP id F1EEB8000B for ; Wed, 19 Feb 2025 03:40:06 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=PmBfPsb0; dmarc=pass (policy=none) header.from=126.com; spf=pass (imf30.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.8 as permitted sender) smtp.mailfrom=yangge1116@126.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739936408; a=rsa-sha256; cv=none; b=HPpt8ulkUy9pDZW4qFpPhb8l0K1ANVP7Rc9QJd6OM48irKeAGY7q4W2aVSUYE82GV1Qzq5 nlYVWZMBBVWOIEYhA1YKZiR4SF7FeQu10NB/BEA3LnHxSWaRRL8wzCc37iOl8ovrmQvfnD l7d/aSR+irlzycM13DqWSECC8ycw/Uc= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=PmBfPsb0; dmarc=pass (policy=none) header.from=126.com; spf=pass (imf30.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.8 as permitted sender) smtp.mailfrom=yangge1116@126.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739936408; 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=VskwbQNxxGXSCd9W0yEExCUDqdZuOrvg+FF0QwLaHys=; b=NHuUwxq2SzOOJATMC/4Dpk00lFw3uVqIpzE7lqJru4BL0ufv0bYqeYIWJZ2Op5XlfzK4vX EUDa1ozQIvg75HkGgsgFIvhdV6LGWq77cESzz4Z9uwMeBaBWkJMRwnDeaC5fJua0XdZm2j KIsCJaT0Tl2Sg2DKs++tghy+BXZp8GI= 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=VskwbQNxxGXSCd9W0yEExCUDqdZuOrvg+FF0QwLaHys=; b=PmBfPsb0HiGDtL3NfDx3O1o1ajAsex+lnq3k3gCigLM5JJV9Nme/u2NlizN+sG gv/ZFVnXui9EqAYC4CCP8YOdE8o2x4b01drz/qh7qegzdi0vWEyi/SLHespbB2Kr 4y/Ciz0tchOPs9bnvQekW4GTvjF3Yi28cImNZKS9dE04E= Received: from [172.19.20.199] (unknown []) by gzsmtp3 (Coremail) with SMTP id PikvCgD3306SUrVnoI4wBA--.1330S2; Wed, 19 Feb 2025 11:40:03 +0800 (CST) Message-ID: <462e8d90-c0d0-474b-851c-46a44282b768@126.com> Date: Wed, 19 Feb 2025 11:40:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V3] mm/hugetlb: wait for hugetlb 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: <1739878828-9960-1-git-send-email-yangge1116@126.com> <17ad5bf5-545c-4418-8d08-459ce6ef54cb@126.com> <950cae5a-bff0-49e6-8fe4-a2447c63d8bc@redhat.com> From: Ge Yang In-Reply-To: <950cae5a-bff0-49e6-8fe4-a2447c63d8bc@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:PikvCgD3306SUrVnoI4wBA--.1330S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxWFy5KrW7tFyrXF4fWF47XFb_yoW5ZFW7pF W5KF13GFWkJr9IyrnFqw1qkw1vkrWjvFW0gr4rtw13CFnIyrn3KFWayw1Y9ayrAr10kF40 qr40qrZxWF1UAaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jjoGQUUUUU= X-Originating-IP: [112.64.138.194] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbifgL4G2e1Un4BNgAAsW X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: F1EEB8000B X-Stat-Signature: 3fgdciq8r59x1esz6erwqyxeth58xi5d X-Rspam-User: X-HE-Tag: 1739936406-738935 X-HE-Meta: U2FsdGVkX19etuHLwnTH6fUAWICWhVdQBIkmHIHE/nGLeBXqlJRejy2EtxPmE/JNuAb05TPbRia7g1wonl06769e+L0ihIqZpEt7X4/px6jKKHYqhSYSEeKAKopTJDMGPeTCmuGbHi361ipxEaaKh3epUEFF2lg5eF52UjkPk5WWZ7eYFr2PNJe16wa3A1uWt0cQ2Kj0URePx9J9P7GV2+RVdJ08Byh3TA0PrUqTVquin3G8DsyqWTJcEvrHp0+VKIrIkxFcQeINNLW/37a/DDDW4UQjftzLYNZySZCrzQljHmgPLL+5vGEUQ2TjUYwy97IwTAYxes2oM6Ph5h4CPvIm9SoTHOgsszRTtnhRHvMUQL91No8wnaYspQZucvPawzfWYu6Ja38s09Zc01qzANsG7IyeWoJl1iK1gisRG30tNj9WISZxiBNwmuBeB/pX++froLCMRHbfXZsUOLJ9KEiwnlG85bESDMnHq4IaVD1fTooADAspTqbfJAslYXL10TPsELQFm2R5jQiwhhJsgLiev5Q2l0l3ebpiMsRt/fbmAE5d19deuwb+4HBybBhVVC5vorYV9GkzRLROmN9+K8ZDxQsz6SUAhop0OVuZNj9Po3tpMpbRyH63SQZeY8RX3BvUsQCYEvahdP9V/YGkdg/deamewjsmeEmb4ELOCDtJf/OIN2kl4/dsOrR1pBHh52Zu7CepHJekrxDlVspzOEcRthzwlPFS3ZPZx3HUuioK3N0qJRdhBpRlMBF1bews/UHwnQXQMPfZD03nZ1C9g8wfJM4mxuXRWGd2yTxYeviBGmaAiZSzBKcrujQZGXVfzOtHJUK5U5sCAGyBKVLvUDuTUJczzD5+ZZ3FTX3RO9+6GSOidj2XJZpbODyq4JAA0NzHEDxPhYVgGnFcemwTZRTU2WUKIeVs8AmqqzDGFBUKGWgNkoiraLLYW82weXbiXn/uFay2jDOA9r/qsR6 NJKz2EqS mR4UqXqmTlXYMZIhda/njlo+CaEICMKxDSXQMJP8vGjuPdMFamgg3uTd4m23GtZL54ZJpIUxKyUiP86aJP8jEtFFd9WTtnD6kvYJ1UQaOEti4cwXTbnxk3AEZJBTRnrSFrJLzADqmhwor28ryJUVE1rZwr7doCNgb3QjbgkpNq10E3vHePlZX6nQ4yNJpBAN3SmlrgvI25jyauAmi3qcZ2qhgVgd1RDlBBj0WJTQiwAdWGcyGgzDYzd5FFE0WHtLI3aBAT7iG5CR7qFBWDq79l/HnqoeJO0Q3JqWQyrcgzgf2hsWfk07hGawoBy9VdHXN6IsXOODm9s7MYQWEmmgvaclGD+ie1FIZk1TwA22AQkZJaXEl7YtRrHz6ZPI3nWTRiYm37oKqOFPBZoq1HbiKiv1Cgae46TuCUrcLwcJhyyjwlRpeK+IXWB7C6A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.002164, 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/19 1:22, David Hildenbrand 写道: > On 18.02.25 13:19, Ge Yang wrote: >> >> >> 在 2025/2/18 19:45, David Hildenbrand 写道: >>> On 18.02.25 12:40, yangge1116@126.com wrote: >>>> From: Ge Yang >>>> >>>> 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. >>>> >>>> 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(). >>>> >>>> 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 >>>> >>>> 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. >>>> >>>> Fixes: c77c0a8ac4c52 ("mm/hugetlb: defer freeing of huge pages if in >>>> non-task context") >>>> Signed-off-by: Ge Yang >>>> Cc: >>> >>> >>> >>> Acked-by: David Hildenbrand >>>> +void wait_for_freed_hugetlb_folios(void) >>>> +{ >>>> +    flush_work(&free_hpage_work); >>> >>> BTW, I was wondering if we could optimize out some calls here by sensing >>> if there is actually work. >>> >> for_each_hstate(h) { >>     if (hugetlb_vmemmap_optimizable(h)) { >>         flush_work(&free_hpage_work); > >         break;>     } >> } >> Is this adjustment okay? > > I think that's better, except that it would still trigger in scenarios > where hugetlb is completely unused if > CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is around. > > Can't we check hpage_freelist? > > if (llist_empty(&hpage_freelist)) >     return; > flush_work(&free_hpage_work); > Ok, thanks. > It should be able to deal with races (we don't care if something is > getting added concurrently, only if there is something right now). >