On 2/8/21 12:50 AM, Muchun Song wrote: > When we free a HugeTLB page to the buddy allocator, we should allocate the > vmemmap pages associated with it. But we may cannot allocate vmemmap pages > when the system is under memory pressure, in this case, we just refuse to > free the HugeTLB page instead of looping forever trying to allocate the > pages. > > Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx> > --- > include/linux/mm.h | 2 ++ > mm/hugetlb.c | 19 ++++++++++++- > mm/hugetlb_vmemmap.c | 30 +++++++++++++++++++++ > mm/hugetlb_vmemmap.h | 6 +++++ > mm/sparse-vmemmap.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++- > 5 files changed, 130 insertions(+), 2 deletions(-) Muchun has done a great job simplifying this patch series and addressing issues as they are brought up. This patch addresses the issue which seems to be the biggest stumbling block to this series. The need to allocate vmemmap pages to dissolve a hugetlb page to the buddy allocator. The way it is addressed in this patch is to simply fail to dissolve the hugetlb page if the vmmemmap pages can not be allocated. IMO, this is an 'acceptable' strategy. If we find ourselves in this situation then we are likely to be hitting other corner cases in the system. I wish there was a perfect way to address this issue, but we have been unable to come up with one. There was a decent discussion about this is a previous version of the series starting here: https://lore.kernel.org/linux-mm/20210126092942.GA10602@linux/ In this thread various other options were suggested and discussed. I would like to come to some agreement on an acceptable way to handle this specific issue. IMO, it makes little sense to continue refining other parts of this series if we can not figure out how to move forward on this issue. It would be great if David H, David R and Michal could share their opinions on this. No need to review details the code yet (unless you want), but let's start a discussion on how to move past this issue if we can. -- Mike Kravetz
