On Fri, Jun 11, 2021 at 5:33 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > 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. Agree. > > 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. Totally right. Coalescing is very complex. So I do not do this in 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/ I've not looked at this deeply. I will go take a look. Thanks Mike. > -- > Mike Kravetz
