Messages in this thread | | | Date | Fri, 20 Nov 2020 09:11:23 +0100 | From | Michal Hocko <> | Subject | Re: [PATCH v5 11/21] mm/hugetlb: Allocate the vmemmap pages associated with each hugetlb page |
| |
On Fri 20-11-20 14:43:15, Muchun Song wrote: [...] > diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > index eda7e3a0b67c..361c4174e222 100644 > --- a/mm/hugetlb_vmemmap.c > +++ b/mm/hugetlb_vmemmap.c > @@ -117,6 +117,8 @@ > #define RESERVE_VMEMMAP_NR 2U > #define RESERVE_VMEMMAP_SIZE (RESERVE_VMEMMAP_NR << PAGE_SHIFT) > #define TAIL_PAGE_REUSE -1 > +#define GFP_VMEMMAP_PAGE \ > + (GFP_KERNEL | __GFP_NOFAIL | __GFP_MEMALLOC)
This is really dangerous! __GFP_MEMALLOC would allow a complete memory depletion. I am not even sure triggering the OOM killer is a reasonable behavior. It is just unexpected that shrinking a hugetlb pool can have destructive side effects. I believe it would be more reasonable to simply refuse to shrink the pool if we cannot free those pages up. This sucks as well but it isn't destructive at least. -- Michal Hocko SUSE Labs
| |