On 6/9/21 5:13 AM, Muchun Song wrote: > In order to reduce the difficulty of code review in series[1]. We disable > huge PMD mapping of vmemmap pages when that feature is enabled. In this > series, we do not disable huge PMD mapping of vmemmap pages anymore. We > will split huge PMD mapping when needed. Thank you Muchun! Adding this functionality should reduce the decisions a sys admin needs to make WRT vmemmap reduction for hugetlb pages. There should be no downside to enabling vmemmap reduction as moving from PMD to PTE mapping happens 'on demand' as hugetlb pages are added to the pool. I just want to clarify something for myself and possibly other reviewers. At hugetlb page allocation time, we move to PTE mappings. When hugetlb pages are freed from the pool we do not attempt coalasce and move back to a PMD mapping. Correct? I am not suggesting we do this and I suspect it is much more complex. Just want to make sure I understand the functionality of this series. BTW - Just before you sent this series I had worked up a version of hugetlb page demote [2] with vmemmap optimizations. That code will need to be reworked. However, if we never coalesce and move back to PMD mappings it might make that effort easier. [2] https://lore.kernel.org/linux-mm/20210309001855.142453-1-mike.kravetz@xxxxxxxxxx/ -- Mike Kravetz
