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 BC8BEC3601A for ; Tue, 1 Apr 2025 08:12:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D50A280005; Tue, 1 Apr 2025 04:12:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6841A280001; Tue, 1 Apr 2025 04:12:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57116280005; Tue, 1 Apr 2025 04:12:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 36883280001 for ; Tue, 1 Apr 2025 04:12:36 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 70187ACD92 for ; Tue, 1 Apr 2025 08:12:37 +0000 (UTC) X-FDA: 83284758354.05.7992285 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf02.hostedemail.com (Postfix) with ESMTP id 460BF8000F for ; Tue, 1 Apr 2025 08:12:33 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743495155; 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; bh=Dc1r8WrWg9PgijSInfYcI2uTb4CKT5zEjnqq5w2tXfo=; b=KkUxmiMSfHBdo/wI+GkIMZXUIbX3bKvw4gNok96leebaX4R/YJ4jdJXkjzmYsC9nppl3kC fr4bNFdbNxkcg5LBbTZzOaxvc667zicgZxZkSorPQYnhK6MH0mYklZjC91GdxPtip03XWX XJOdD2NPPT2y6CGOZmkmB0dYyzWjV+I= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liushixin2@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743495155; a=rsa-sha256; cv=none; b=fDy/0VcFX6j674UUHLI0VXx0vx2gfIODeKrZYlCjQgg2hNPq39kwCvDgszdT4MCU+SBTKn R9PrMKGCAHw5BkWSvtrg4nPSilaVcMlOyYtv1Oql27bWMBr2UKGm3Sj5/dbFyiwlnjXhl1 YvSy8ALS133aDcR8nV3U+auJc6B+K0A= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4ZRghJ0zsFz13L7w; Tue, 1 Apr 2025 16:12:00 +0800 (CST) Received: from kwepemg200013.china.huawei.com (unknown [7.202.181.64]) by mail.maildlp.com (Postfix) with ESMTPS id 87BD6180080; Tue, 1 Apr 2025 16:12:30 +0800 (CST) Received: from [10.174.179.24] (10.174.179.24) by kwepemg200013.china.huawei.com (7.202.181.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 1 Apr 2025 16:12:29 +0800 Subject: Re: [PATCH v3] mm/hugetlb: update nr_huge_pages and surplus_huge_pages together To: Muchun Song , Andrew Morton , David Hildenbrand , Oscar Salvador , Kefeng Wang , Peter Xu References: <20250305035409.2391344-1-liushixin2@huawei.com> CC: , From: Liu Shixin Message-ID: <8f63f6bd-41ab-c819-291c-f66c239da27b@huawei.com> Date: Tue, 1 Apr 2025 16:12:29 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20250305035409.2391344-1-liushixin2@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemg200013.china.huawei.com (7.202.181.64) X-Rspamd-Queue-Id: 460BF8000F X-Stat-Signature: guggmybsni6x474apow49eeuz67iu3cu X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743495153-447788 X-HE-Meta: U2FsdGVkX18JTLj5CkZuzROo6i4elyvDurXepajlCZ9+6lduAknzxxHZ1mGVKD7U0Tyf6B8vuwoLZmTWDxaLCOG27j9ZUvnVEkh91fOSgq+QOOnoPXyhvqS6M8WXlZv5DpzOhst2PQHdRyjAz2NKPqvF8YdMb9+eKxaxjURc+xlsQdVJ/DiJ2PKNSYFlGXipwEGBAXHqFKqAGTH8uoyz92crzsUmIZqF6ZZwOODryxcCIbFrV1YjMulasRiVHbEExSq5iBsBK57vYqiS7J7KsSiah93TpPdLeGWGwVR0e5VXJ78JS6Y20plTLzEfc8KmxFAzkIFG/PlCHP3qy9P2mU9scZEEChaBr54MfdA/XF3psKhrd8T8b/bpm3m74ftdAdlOWc4KrUi9WsJqpCIh/na4fZE3DdcnfU1fyGBQNmYQaJ+S9vMXeXvjwvuKJpjpE78OJFeRBW4oCnQig51Aid8cDk9pTD90nweKsLSPnKTKRLpz031QDgPmaP5qJ5dNhHJhrR/Tp205SjTCbUjW4RnA2bDDTqfF6SLzmHvCexhzUgzGR58V5PVVNINr5LT9XgPtExSsFk39rF51EnKG3Pfw7TxyJ+nzUpXbeDKu0OYi61xcvlLfMuOjyd9qJa68NLXWQpPMulUc0UdC7zjYgD21W6iO3Tk5uoUESenahM202RJMzYFZwDBTg97+JDr3BpFPw4OG0y65jjL7aDmdp79ezJ2NoZ80d0BgOzTf+ESC0V0S0BITgSD8pdG7/DD2l41R0xrW4fBT4zWw+6gyoKRfimXH17MB0dFQaw+brlaRfEGZmNosXCpjt/g/70UWb8mHCeQxyqa7Cu7E0xOmdeJlajOVpWFEh7+RyMMVkfoQgSMxsfXXj/GbnXpxpum/P2Da3IgVnsfG5igYWm+G6mmrKCH3C69DOsyCjvAnuEtYTAe8QeLxHKEyQCUW1dtw6ygIOC5Sz1La1U4zrRe nG4RrioZ q+KzrPEm/m5bHg875EPzkhGixSXRC/kqt5DrEKcKcUEfH1SQQJceKTAVV/AHsuZGhxi93RCsfUdFrzF1dsIhvpYMonte/LhXpMrycQ7ofw0jFC43bQpY1g8i0Xph6BNkDfuov+T8HJ1PWEDV3yA/W7RVDJQF0hM4sgVjixT80XWDXRhbUxATwyzvTgFQSQ2kfHZRUS5nurbSNxyg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2025/3/5 11:54, Liu Shixin wrote: > In alloc_surplus_hugetlb_folio(), we increase nr_huge_pages and > surplus_huge_pages separately. In the middle window, if we set > nr_hugepages to smaller and satisfy count < persistent_huge_pages(h), > the surplus_huge_pages will be increased by adjust_pool_surplus(). > > After adding delay in the middle window, we can reproduce the problem > easily by following step: > > 1. echo 3 > /proc/sys/vm/nr_overcommit_hugepages > 2. mmap two hugepages. When nr_huge_pages=2 and surplus_huge_pages=1, > goto step 3. > 3. echo 0 > /proc/sys/vm/nr_huge_pages > > Finally, nr_huge_pages is less than surplus_huge_pages. > > To fix the problem, call only_alloc_fresh_hugetlb_folio() instead and > move down __prep_account_new_huge_page() into the hugetlb_lock. > > Fixes: 0c397daea1d4 ("mm, hugetlb: further simplify hugetlb allocation API") > Signed-off-by: Liu Shixin > --- > v2->v3: Modify the comment suggested by Oscar. > mm/hugetlb.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 9faa1034704ff..0e08d2fff2360 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2253,11 +2253,20 @@ static struct folio *alloc_surplus_hugetlb_folio(struct hstate *h, > goto out_unlock; > spin_unlock_irq(&hugetlb_lock); > > - folio = alloc_fresh_hugetlb_folio(h, gfp_mask, nid, nmask); > + folio = only_alloc_fresh_hugetlb_folio(h, gfp_mask, nid, nmask, NULL); > if (!folio) > return NULL; > > + hugetlb_vmemmap_optimize_folio(h, folio); > + > spin_lock_irq(&hugetlb_lock); > + /* > + * nr_huge_pages needs to be adjusted within the same lock cycle > + * as surplus_pages, otherwise it might confuse > + * persistent_huge_pages() momentarily. > + */ > + __prep_account_new_huge_page(h, nid); > + > /* > * We could have raced with the pool size change. > * Double check that and simply deallocate the new page Hi, Sorry, there's a mistake that the nid may be mismatch. Please use the following code to fix it, or should I send a fix patch ? diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 39f92aad7bd1..6670f9b9e07a 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2271,7 +2271,7 @@ static struct folio *alloc_surplus_hugetlb_folio(struct hstate *h, * as surplus_pages, otherwise it might confuse * persistent_huge_pages() momentarily. */ - __prep_account_new_huge_page(h, nid); + __prep_account_new_huge_page(h, folio_nid(folio)); /* * We could have raced with the pool size change.