| Message ID | 20230906063423.99395-1-yuancan@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: hugetlb_vmemmap: avoid allocation failure message in alloc_vmemmap_page_list() | expand |
> 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 >
在 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 >>
> On Sep 6, 2023, at 15:22, Yuan Can <yuancan@huawei.com> wrote: > > > 在 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()? Do not do this. We need a warning here. Thanks. > > 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
在 2023/9/6 15:25, Muchun Song 写道: > >> On Sep 6, 2023, at 15:22, Yuan Can <yuancan@huawei.com> wrote: >> >> >> 在 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()? > Do not do this. We need a warning here. > > Thanks. Ok, thanks for the reply.
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;
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. 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(-)