Re: [PATCH 0/5] Split huge PMD mapping of vmemmap pages

[Mike Kravetz]

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