Re: [PATCH v5 11/21] mm/hugetlb: Allocate the vmemmap pages associated with each hugetlb page

[Michal Hocko]

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