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 BE35BC02198 for ; Tue, 18 Feb 2025 12:36:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42FB56B0173; Tue, 18 Feb 2025 07:36:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DFDB2800D5; Tue, 18 Feb 2025 07:36:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A82C6B0175; Tue, 18 Feb 2025 07:36:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0A2446B0173 for ; Tue, 18 Feb 2025 07:36:42 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DCCC014108B for ; Tue, 18 Feb 2025 12:36:37 +0000 (UTC) X-FDA: 83133014034.02.18B75EE Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.6]) by imf21.hostedemail.com (Postfix) with ESMTP id 381C41C0009 for ; Tue, 18 Feb 2025 12:36:33 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=UFmOU2AJ; spf=pass (imf21.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.6 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=1739882195; 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=PjVps/mbL29xZmKfD5xoWxmNLay5V9tgBzGtJ2OKIkM=; b=SDErM8cOK/FKz0J7NFu6N8fSvWXocOpkXyAaWrm3DefXExYV5EXdAQoM0+Y0lbafAy7Sdi Q822UZzwvU+LeiV37758LxgPQMRjNJKMmNpUNTDB1iMQ1Up8LQF1CNdzEkZFQgq+kFkICo tn7OHezbprL3eThdRhTrjwYVDCJEnaw= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=UFmOU2AJ; spf=pass (imf21.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.6 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739882195; a=rsa-sha256; cv=none; b=l4JkEaECMTC/RzGQxJF/6wHFW6GX4udsqGcx11DnkkJxcFAklF6hS60oUSWy1FnJyqxSyv px3fifD0qivRTEgDnufyGbm8AOrMrn/Igt4fVFnhY5kSEdc/RMfzDPL/w3/IpWN+eR6O1H rd9rpojul0K45WRK+s1aoZa2+lL02HE= 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=PjVps/mbL29xZmKfD5xoWxmNLay5V9tgBzGtJ2OKIkM=; b=UFmOU2AJs0pnz9fhcg4UtLj5zdpnEgMCDNnW5z7A/7nKvIXAp7gY3jlvIF01NC pKTYYT/FjYW5Wiuz29BOeM19S7TsYOhoAoqKuYJ2trqiVNHuqYFPDo0DOwK3ajE+ QBbgnfN1dOA1hC5YKl6OziGLPtQLNFA5mgRphBSn+g25k= Received: from [172.19.20.199] (unknown []) by gzga-smtp-mtada-g0-3 (Coremail) with SMTP id _____wD3n4TverRnbKJTBA--.2790S2; Tue, 18 Feb 2025 20:19:59 +0800 (CST) Message-ID: <17ad5bf5-545c-4418-8d08-459ce6ef54cb@126.com> Date: Tue, 18 Feb 2025 20:19:58 +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> From: Ge Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3n4TverRnbKJTBA--.2790S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxWFy5tw4DuFWkXw1kJw4UCFg_yoW5XFyrpF WUKr13GFWDJrZakrn2qw4vkw10krWDZFWxKr4Sq3y3uFnxJ3s7KFyav3Z0gay8Cr1SkrW8 trWvqrsruFyUZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jjYL9UUUUU= X-Originating-IP: [112.64.138.194] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbifhT3G2e0c8dX-gAAsI X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 381C41C0009 X-Stat-Signature: m7zz7otd7efqxp3dtehtfgsy436uitqw X-HE-Tag: 1739882193-148767 X-HE-Meta: U2FsdGVkX1+Kp15JCgKNcMrCWO+y/rAiZDIhoSvRvR8hQzGUPxVeuhhQ/VHTMwXawL9hEdCbo8ikYc4Rr+J80lseUjq1DHMNdvQAPhG9C/VN19WO6dnRCvABxgDVdWkgKUp4m/Gyh2UbdzHvCtfQFGD+esN3K07NiI5gDqtlvwvWgmPGO0E9abjYhPl9qPLhWV5H2hvlPEYEjawQTorUM1qsLouNYZRDHQvntMDrLzasGFFecshlVuf8n5CoEARBmLcVk9C/edpzPpsxP6uGVJ8Ka5zzitkxud0iHW1nSakM/HUAUiewZYZfRjoesCvi7ZCwRaccElFl32y7WVnqhH5rMM/q0Qo1Q6roOSWds83NpGtbDVlzMnPgUqDi0Vvsa+han1zqwYCOswdfLYb+vEn20Z6Txr84lriglICXa2VbObjHCzpCTGpPfv3f+f3eZKutgdp0C4tTrumElkYMIeHXeUJBvO9XhT92Cn5ry/wTLLpZgkLS25UU2egMPAnnqPQdRZz2f9k+2v6cAM4NrDk0WAGKDgWX8fctgIDnAqKuxF8bqSM8wB18+CZBqSBWkdQs62B1QFrwKEFwVDfAsuMKjQAMHOffZd5KgTA88bPNxx3OOcUYC+n58vsoVlxdAWR/aVmW8YKjPSt4aSAAoYFKIXaCa/9WCXJV8EavuXV2yXpHiw52wE7TZKPv5WiXDY0hKCbi9Ba8vrmDmTiw9B6CjniigdIEh0K92I2qNuQ48UpwHWXLKW7//VtlbTnJtAdh2RMeyGQjry+XySDfurxINKWHbZP8iaExKzuD1m2Pb2z50ley5dMofJu4PuSEZWYc8BduUGOOn2PxUTi7LwOcZjZqQQlshfBbMBUYcsGv2i5GMUeyYnYuy3RgqsSRyuPdiiQ5IGK7oACAFKDPsVPMFyPHM0MIt6ZW334IZxNl5Nm/1SRaj1NjBnruurBGQ35u6beMvVwXbHM2iF2 34DO0DpD jY3zZiLonh+GXUFwkrqa48m1SivPJRenflUVR03/7hOzUzWyhYFmScb/dleF8b3AgfdgrXtSHeoj4KxZXyEiELokzJWpRT1ZcKBvmu7PIw/z1oX15ZffDDj5R5Oikbv1EX/pcsfYeb1GTaOoEjnDsnhQ9xBCzW3P9miHTWMluWgTFU3Nv5PKcg4cJ6gY/wT9TSrJDMyyWemE1bzQ6yYD8J1KbGPQU5+sshjee6vbumH/nRffn0LPNU6WrWmjg3qVmcjMKORT+Hry3RlaBDajMlStJXsEjN059hElTBm+YzPhwSEkn6hB8Mf1wBmf/mnpY0DL7jXhZgRt045y/ui+JaJKm3uuRFucqEib1lJ/6JNCnJa9nrE7FyA0wJj25T9NZYGzxnxyimdswaieiXG2ED6ThFIdsFan4YB+dz4lJPnBOi44hdrHUFeWpQQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.031999, 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 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? > In most cases, we'll never ever have to actually wait here, especially > on systems without any configured hugetlb pages etc ... > > It's rather a corner case that we have to wait here on most systems. >