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 0F7B5E77197 for ; Thu, 9 Jan 2025 09:50:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D3796B0083; Thu, 9 Jan 2025 04:50:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 983866B0085; Thu, 9 Jan 2025 04:50:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8739D6B0088; Thu, 9 Jan 2025 04:50:51 -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 6A9536B0083 for ; Thu, 9 Jan 2025 04:50:51 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E470F140C55 for ; Thu, 9 Jan 2025 09:50:50 +0000 (UTC) X-FDA: 82987444260.19.BD88B96 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.8]) by imf24.hostedemail.com (Postfix) with ESMTP id 31C33180008 for ; Thu, 9 Jan 2025 09:50:47 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=RQPcjC8W; spf=pass (imf24.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.8 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=1736416249; 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=jIsY2cpnT+tIRQNZjatzrDUodDqoUKk2a2OvKJzbtbo=; b=UAGA96M1UhH++bKEkEcjtjs/x3VB97fXB7AkS2rxbgkpqhbWUtf0p2DpfPC0jINGzPq8Vj kavTcyBZ939AuyUax35hS6RZgrAPQmwd4c7aYqosyjfnP6t7xpB4YLmEOKSjuvASUvxY3K WHZi78OGgeFhftMSeriap9xLFZxR+8Q= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736416249; a=rsa-sha256; cv=none; b=3rEA696R6aFWO0VvUBT2RpsjS5HsyyCIn/NwZfengkhXboOFa2g8fsgDKgyCPNukdgDmGm JG8WHzK9J0WR0mE6lRpG4GV07hJGkkIA5LyeJBSYC20V9pTrnL5aNNCv/POJ4jwoJaWuj1 3MWxBnp8oyN11yVq2KEw6WxQ9zqTSnk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=RQPcjC8W; spf=pass (imf24.hostedemail.com: domain of yangge1116@126.com designates 220.197.31.8 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=jIsY2cpnT+tIRQNZjatzrDUodDqoUKk2a2OvKJzbtbo=; b=RQPcjC8WlK3c6OA6bErtZWOMjElDPHSD4M2JJSusT9hI1rbXZMfyrrT/swirY9 R2IeAynSlDPhtibO0MRMBnGK5pTHH4m2uJHAUTL/TKOwAk/OYyjwode9xBq4hgXs nvrWoXPbJwJHMLWF2+XHbJGCHNCp0ICj6bi8+mUkVQYE0= Received: from [172.19.20.199] (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wD3v6Xwm39nae7KAw--.35704S2; Thu, 09 Jan 2025 17:50:41 +0800 (CST) Message-ID: <85bfb9b7-09fc-45e3-888d-71c848aaf00d@126.com> Date: Thu, 9 Jan 2025 17:50:40 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] replace free hugepage folios after migration 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, liuzixing@hygon.cn References: <1734503588-16254-1-git-send-email-yangge1116@126.com> <0ca35fe5-9799-4518-9fb1-701c88501a8d@redhat.com> From: Ge Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3v6Xwm39nae7KAw--.35704S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxAF1DZF4fAryDAr43JrWxtFb_yoW5WFykpF 4xKrW3GayDXF9Fkr1vqw48Jr18u3yxGrW8JF4fKrWruFnxXry7KFnFvwn5uayIkF1FyF4I vr4qv3srKF1DZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jbHUDUUUUU= X-Originating-IP: [112.64.138.194] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbifgrPG2d-mgcakAAAsv X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 31C33180008 X-Stat-Signature: ok3eyf4zhapr6m4npmqatjorksrpr8gh X-Rspam-User: X-HE-Tag: 1736416247-170617 X-HE-Meta: U2FsdGVkX18xd2qMVvbGtGWPj5V6oz5Fcu0ScV/fx3lbyQ4DJKBA1HBUuQZ+mEhhLpZYKjgt5enswEzLfrN1cXFlQqoLAfzqeqSf5MLK05fshuBGH1X9Ak5ShMiTGP0ZzUQeIXWaAf9CJWuEzQ7O/NePWHTU5cHhaBVlhXKc7a3Ax3Zw4HsK0cUzGp5Nie+0Eop5MQgjULqlNQnkrkJ522MwBmGFH64DmZ2frE2EW/Xgj/M0b/fPlU950krvJpBpixsCF92QuSrflUWi1iU1g3107v83fOb3QyEztp6ONQe1sy4X9dz7ZCqoaoa919tZeFaAWQX05EWzaOybNjrvcfQUaSYy325RaU3V5sggN178DRdJZuyjVlGrw4rB36cbT08O8d7pnJAIo/l7NfNJ/D1LlhyIrhyIxkv6PZ3P4LLdZc/IvdPEfIDm66YOH4Yq2hZzBgGCLd+/Bzx8n0mpST3vUpVKcNXb1l7pDA3W/11f6M66jZ+bpEemEa/ma2FbGSjjX8HTsbaqG56dON2cgPF6JOLm6qbTc1f+pe2o4pvOTyp4GdUOQqpOtACjJJR+9yYUSqze011yNMPSxShRd5RM3E5X7YIWbHSs5aein4P2f/jqELU10bmgCHlh9rWIZKN4rDymiaGV4Fo//vmRFpAr/ZZ/vXoyI8ih149GFml7a61L3YvWzHL8pKFgUD43tYzNJgue1QDln9y3PwPM52DBuXvdyp3Rlag+kCTd7n5+g5qI7Wxp+eeA6MRUG4WZRXAw0cHREYP06uX6eDXQttcPSQcIv2FJ+gnSth7FS6erYySV7vMw6JZugkewGHxSV4xzo+aKOzRo+ABC4U//j6M9PiSKbEgTDsvymlQ3MOcTo4pX6b668xmyhV38ZZ4Zx0b93K15iJE1IkielxSfxjAyjVVJuzCpj9GAlQ3sA4VIgQLNmVo3NpaXiKQLKtjVVYD4vCevPdBHndwgdbO rI8JT4U7 abAGA9+HMjJrPWDFJhtkFywIOhwabZ1JoUF5gU1nEZjRSUXrGDQh2tHswQqfPYOIewYPPXR5K3Y/T8Dh/5OxMhBolVsJnlKFk3oKCKn9O0aBnJpeGtVC5R54cJm9flQvF4WclLIygEW5dp0F1rv4abM5e4lqD5C23Sd4XNugZbT1jQkfh/HyW/cQqxQ8YQgApQiDpb3IuRBlFBZ7bE+V61jqKJdhGzS0FOXiew3sr24jg9/hfgHeFt3vNUxzFEPfo255xtZ6a9o/UVFv/dS9XEoEpzzsWoxo2MPHm7y4O1owjZAbpLUXacjHbaOLm/pxUHC2vnPn0BuG03FA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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/1/9 5:05, David Hildenbrand 写道: > Sorry for the late reply, holidays ... > >>> Did you ever try allocating a larger range with a single >>> alloc_contig_range() call, that possibly has to migrate multiple hugetlb >>> folios in one go (and maybe just allocates one of the just-freed hugetlb >>> folios as migration target)? >>> >> >> I have tried using a single alloc_contig_range() call to allocate a >> larger contiguous range, and it works properly. This is because during >> the period between __alloc_contig_migrate_range() and >> isolate_freepages_range(), no one allocates a hugetlb folio from the >> free hugetlb pool. > > Did you trigger the following as well? > > alloc_contig_range() that covers multiple in-use hugetlb pages, like > > [ huge 0 ] [ huge 1 ] [ huge 2 ] [ huge 3 ] > > I assume the following happens: > > To migrate huge 0, we have to allocate a fresh page from the buddy. > After migration, we return now-free huge 0 to the pool. > > To migrate huge 1, we can just grab now-free huge 0 from the pool, and > not allocate a fresh one from the buddy. > > At least that's my impression when reading alloc_migration_target()- > >alloc_hugetlb_folio_nodemask(). Thank you very much for your suggestions. It needs to be discussed in two different scenarios: 1, When All Free HugeTLB Pages in the Pool Are Allocated, available_huge_page() Returns false If available_huge_page() returns false, indicating that no free huge pages are available in the hugeTLB pool, we will invoke alloc_migrate_hugetlb_folio() to allocate a new folio. A temporary flag will be set on this new folio. After the migration of the hugeTLB folio is completed, the temporary flag will be transferred from the new folio to the old one. Any folio with the temporary flag, when freed, will be directly released to the buddy allocator. 2, When Some Free HugeTLB Pages in the Pool Are Still Available, available_huge_page() Returns true If available_huge_page() returns true, indicating that there are still free huge pages available in the hugeTLB pool, we will call dequeue_hugetlb_folio_node() to allocate a new folio. After the migration of the hugeTLB folio is completed, the old folio will be released back to the free hugeTLB pool. However, this scenario may pose potential issues, as you mentioned earlier. It seems that the issue can be resolved by the following approach: dequeue_hugetlb_folio_node_exact() { list_for_each_entry(folio, &h->hugepage_freelists[nid], lru) { if (is_migrate_isolate_page(folio)) { //determine whether a hugetlb page is isolated continue; } } } > > Or is for some reason available_huge_pages()==false and we always end up > in alloc_migrate_hugetlb_folio()->alloc_fresh_hugetlb_folio()? > > Sorry for the stupid questions, the code is complicated, and I cannot > see how this would work. >