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 C34A9EB8FA5 for ; Wed, 6 Sep 2023 07:22:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A28D280004; Wed, 6 Sep 2023 03:22:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42B798E0014; Wed, 6 Sep 2023 03:22:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 31A36280004; Wed, 6 Sep 2023 03:22:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 20D428E0014 for ; Wed, 6 Sep 2023 03:22:51 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E04341CA95D for ; Wed, 6 Sep 2023 07:22:50 +0000 (UTC) X-FDA: 81205330500.24.1BD1DDD Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf11.hostedemail.com (Postfix) with ESMTP id 9C50C4000B for ; Wed, 6 Sep 2023 07:22:46 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of yuancan@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=yuancan@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693984968; 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: in-reply-to:in-reply-to:references:references; bh=bi/akb7kpcu6S0LuvPoAr/9eLFutvtRo0WahIFsNH4I=; b=pmv7TjzTTA1Tll6tGQeuxOqIo8dz8aAlfcaFQLyLDh+Es6k3V6pkifggjQi3ebvfbC6ZQe GwVRENHV0E5eNrKkqg+JTLb4BjFQ5npRO1b0AeBzgOV6jlox3nNMEkCnJmA8j11/pTwBpq UOiwwk9PmZ/84E7dose5sgFM1rh5aZo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of yuancan@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=yuancan@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693984968; a=rsa-sha256; cv=none; b=Y8swIZ6uvk9BEiofo/I0XfGs1WKbTrHy0hcSRoRcSS6rr8jvB0h4cLlirbicqi3O98x7Gl pZrb2BSXlQzLfgNxAV0w6fGr+70Oeqa/idyd7aH/I3076fscoPZpjcJWH3R7jhG9kscp9/ wdqrZu3wxrCN8z+927KOteKHNUQYCWY= Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4RgYgl4ZHqz1M8wP; Wed, 6 Sep 2023 15:20:51 +0800 (CST) Received: from [10.174.178.41] (10.174.178.41) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Wed, 6 Sep 2023 15:22:38 +0800 Content-Type: multipart/alternative; boundary="------------agWNTcJ7CR5dpdIn6rgE8utG" Message-ID: Date: Wed, 6 Sep 2023 15:22:38 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH] mm: hugetlb_vmemmap: avoid allocation failure message in alloc_vmemmap_page_list() To: Muchun Song CC: Mike Kravetz , Andrew Morton , Linux-MM , Kefeng Wang References: <20230906063423.99395-1-yuancan@huawei.com> From: Yuan Can In-Reply-To: X-Originating-IP: [10.174.178.41] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9C50C4000B X-Stat-Signature: itet59wangmxfr4n34595fey739fympw X-HE-Tag: 1693984966-953057 X-HE-Meta: U2FsdGVkX1+5yQuQy1fJoXbXXcj+PDNQX9m52HqQZzosnarSIyNpKzRlPAuKIEWqnXFSDWd13gXe1at/5IGMj7jYs5DGX26DTND9RXERAj8QdPpx2kRPdpubtZN8DVwv1+U/JE+yvbTAk15IWm2Uk+r55AmWRTbiISJMnwb4TVHkYn72+0LvbAlsppmlQDPhpCC+QrmIXBNSM6Zg892U+bNFqwKeS/eyjNt4bAKxB7VgBPvAxge0qfBRljAYld+g3lBBt36S9NkkJcps0dtMobdWeoYjKUMjWPy7AjkCz68/dokQvxikVpLDt/dP5eM/ZBksheqli6A0uBaxOf3aOVbl13UKGNlfyumAKNN8zjXH/3geLILAZPyXDyo7RLOtH9XvMzckLJ655ZsVbWMC09o3QCErgigIEeeSDXu80dtDypu/5mbTSO1dninvVoIzoE1IJFlA0aR+BK2myq3hUEzfRmtri/2Ccip+ByVFQXJun8WHewnB1q6OCXiME28jvTRCpznXlJ5nawakC5N+soNHvvhKylcCOV7+tAETY1/DUjwRx5QpEl56jpEDh/EO6amTRokQU/KMG9qby6b9vDjRunGQT1UH9f/FNH//DwQYDlgTAi1dY3HSnTQ1deftXtFQ4lt+ASWTL5vKHxcGvs74CgdeTItZG159EI4kZsRX/EJiJVs/2+XY7bjB4gba9htD3fAzWc0EF3H6VWBmHqFvEeTB0yXjHohknd9gwW1g2+4/hXfVAdfkY79nf2OBgII+WoppApHV0s7KyLDxfDyHdijupfiBrpduQpMYUG8qimcgmwY0JtoceTrFv1Q+cJA6wO4dqSqyJxZXOGPNs3ZYC8beB+2ljMBDVEqWZpQ+odv0yPBxMFghzLz+ByklS3vkcJaDgq0ffH0mX2ebscBqSE46Y6ms6hqj7RyKSBzrsJ1d82DUco0pM1WvhDeT2VQV0C008VTxZIdSdo+ jKVckKDi FUrGRB7Rt7I91nKM2JcZRT/kD1LKvgvrMEgjtRMO6eoej88QLvGcL18lL4tu8Ay0eeY4CQjSia6dLjmcFmTwQyNbgqgAz19dz8vgccv8EJvI3AD+Rx9Rq4wsoOfecLAYVAncwaA3TGQOn44UzdV4OIWucQzlwbQ+bESMB+F17d8U4FAhG4qxdp90ZNiFySfA1mz7Z0l47Ymu+f1/VCB9VW2PwFuK3bVrc1zUQfCbABBn0lefGFrkprdgKpR1go2mj6keHlENwfHjduCXxl6XoaGXRUY6e1gyn3t3haZR0ZEivJbC2SQogvZHRz+uDO9CZ8jXJ9sfhbfh4gcT6Lzyj2mtbmkgA91FifC3J7sG+XUnzErS7F8P2oOL/I23VPsYc9j0iU+fhdtflLpoqWBUv8JWREA== 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: --------------agWNTcJ7CR5dpdIn6rgE8utG Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 在 2023/9/6 14:52, Muchun Song 写道: > >> On Sep 6, 2023, at 14:34, Yuan Can wrote: >> >> When vmemmap pages allocation failed, the hugetlb pages fail to free, >> which is not an fatel error, so avoid the allocation failure report by >> passing __GFP_NOWARN in gfp_mask. > You have misunderstand me and Mike. We mean the memory allocation > in vmemmap_remap_free() which also use __GFP_THISNODE, it has the > same issue as you fixed in another thread. But the failure of memory > allocation is not fetal. And it is better to remove __GFP_THISNODE > as well. > > Thanks. Ok, sorry about this, I will send another patch to remove __GFP_THISNODE in vmemmap_remap_free, and I would like to know is it ok to add __GFP_NOWARN in alloc_vmemmap_page_list()? Thanks. >> Suggested-by: Mike Kravetz >> Suggested-by: Muchun Song >> Signed-off-by: Yuan Can >> --- >> mm/hugetlb_vmemmap.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c >> index 0485e471d224..3fa6b6e2bf45 100644 >> --- a/mm/hugetlb_vmemmap.c >> +++ b/mm/hugetlb_vmemmap.c >> @@ -386,7 +386,7 @@ static int vmemmap_remap_free(unsigned long start, unsigned long end, >> static int alloc_vmemmap_page_list(unsigned long start, unsigned long end, >> struct list_head *list) >> { >> - gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL; >> + gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN; >> unsigned long nr_pages = (end - start) >> PAGE_SHIFT; >> int nid = page_to_nid((struct page *)start); >> struct page *page, *next; >> -- >> 2.17.1 >> -- Best regards, Yuan Can --------------agWNTcJ7CR5dpdIn6rgE8utG Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit


在 2023/9/6 14:52, Muchun Song 写道:


On Sep 6, 2023, at 14:34, Yuan Can <yuancan@huawei.com> wrote:

When vmemmap pages allocation failed, the hugetlb pages fail to free,
which is not an fatel error, so avoid the allocation failure report by
passing __GFP_NOWARN in gfp_mask.

You have misunderstand me and Mike. We mean the memory allocation
in vmemmap_remap_free() which also use __GFP_THISNODE, it has the
same issue as you fixed in another thread. But the failure of memory
allocation is not fetal. And it is better to remove __GFP_THISNODE
as well.

Thanks.

Ok, sorry about this, I will send another patch to remove __GFP_THISNODE in
vmemmap_remap_free, and I would like to know is it ok to add __GFP_NOWARN in
alloc_vmemmap_page_list()?

Thanks.



      

        
Suggested-by: Mike Kravetz <mike.kravetz@oracle.com>
Suggested-by: Muchun Song <songmuchun@bytedance.com>
Signed-off-by: Yuan Can <yuancan@huawei.com>
---
mm/hugetlb_vmemmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c
index 0485e471d224..3fa6b6e2bf45 100644
--- a/mm/hugetlb_vmemmap.c
+++ b/mm/hugetlb_vmemmap.c
@@ -386,7 +386,7 @@ static int vmemmap_remap_free(unsigned long start, unsigned long end,
static int alloc_vmemmap_page_list(unsigned long start, unsigned long end,
  struct list_head *list)
{
- 	gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL;
+ 	gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
	unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
	int nid = page_to_nid((struct page *)start);
	struct page *page, *next;
-- 
2.17.1



      

      

    

    
-- 
Best regards,
Yuan Can

  


--------------agWNTcJ7CR5dpdIn6rgE8utG--