From: Muchun Song <muchun.song@linux.dev>
To: Yuan Can <yuancan@huawei.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: Re: [PATCH] mm: hugetlb_vmemmap: avoid allocation failure message in alloc_vmemmap_page_list()
Date: Wed, 6 Sep 2023 14:52:30 +0800 [thread overview]
Message-ID: <ED1E0584-1833-4B06-8915-4DD173860152@linux.dev> (raw)
In-Reply-To: <20230906063423.99395-1-yuancan@huawei.com>
> 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.
>
> 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
>
next prev parent reply other threads:[~2023-09-06 6:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-06 6:34 [PATCH] mm: hugetlb_vmemmap: avoid allocation failure message in alloc_vmemmap_page_list() Yuan Can
2023-09-06 6:52 ` Muchun Song [this message]
2023-09-06 7:22 ` Yuan Can
2023-09-06 7:25 ` Muchun Song
2023-09-06 7:29 ` Yuan Can
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ED1E0584-1833-4B06-8915-4DD173860152@linux.dev \
--to=muchun.song@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=wangkefeng.wang@huawei.com \
--cc=yuancan@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.