[v2,0/3] Split huge PMD mapping of vmemmap pages

Message

Muchun Song June 12, 2021, 9:45 a.m. UTC

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. When HugeTLB pages are freed from
the pool we do not attempt coalasce and move back to a PMD mapping because
it is much more complex.

[1] https://lore.kernel.org/linux-doc/[e-mail]/

Changelog in v2:
  1. Collect Review-by from Mike.
  2. Remove helpers used to preallocate/free page tables for HugeTLB pages.

  Thanks Mike's suggestions. It really eliminate a lot of code.

Muchun Song (3):
  mm: sparsemem: split the huge PMD mapping of vmemmap pages
  mm: sparsemem: use huge PMD mapping for vmemmap pages
  mm: hugetlb: introduce CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON

 Documentation/admin-guide/kernel-parameters.txt |  10 +-
 arch/x86/mm/init_64.c                           |   8 +-
 fs/Kconfig                                      |  10 ++
 include/linux/hugetlb.h                         |  25 +---
 include/linux/mm.h                              |   4 +-
 mm/hugetlb_vmemmap.c                            |  11 +-
 mm/memory_hotplug.c                             |   2 +-
 mm/sparse-vmemmap.c                             | 157 ++++++++++++++++++------
 8 files changed, 149 insertions(+), 78 deletions(-)

Comments

Andrew Morton June 15, 2021, 1:12 a.m. UTC | #1

On Sat, 12 Jun 2021 17:45:52 +0800 Muchun Song <[e-mail]> 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. When HugeTLB pages are freed from
> the pool we do not attempt coalasce and move back to a PMD mapping because
> it is much more complex.
> 
> [1] https://lore.kernel.org/linux-doc/[e-mail]/

[1] had a nice [0/n] description but the v2 series lost that.  I could
copy/paste the v1 changelogging but I am unsure that it has been
maintained appropriately for the v2 series.

I think I'll pass on this v2 pending additional review input.  Please reinstate
the [0/n] overview if/when resending?

Mike Kravetz June 15, 2021, 3:52 a.m. UTC | #2

On 6/14/21 6:12 PM, Andrew Morton wrote:
> On Sat, 12 Jun 2021 17:45:52 +0800 Muchun Song <[e-mail]> 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. When HugeTLB pages are freed from
>> the pool we do not attempt coalasce and move back to a PMD mapping because
>> it is much more complex.
>>
>> [1] https://lore.kernel.org/linux-doc/[e-mail]/
> 
> [1] had a nice [0/n] description but the v2 series lost that.  I could
> copy/paste the v1 changelogging but I am unsure that it has been
> maintained appropriately for the v2 series.
> 
> I think I'll pass on this v2 pending additional review input.  Please reinstate
> the [0/n] overview if/when resending?

There may be some confusion.

This series is a follow on optimization for the functionality provided by
[1].  Early in the development of [1], it was decided to drop some code
for ease of review.  Specifically, splitting vmemmap PMD mappings to PTE
mappings as required when hugetlb pages were allocated.  The
'simplification' in [1] is that if the feature is enabled then vmemmap
will only be mapped with PTEs.

This series provides the ability to split PMD mappings 'on demand' as
hugetlb pages are allocated.  As mentioned, it really is a follow on and
optimization to functionality provided in [1].  As such, I am not sure
that repeating the [0/n] description from 1 is necessary here.

In any case, this should be clearly stated in the [0/n] description of
this series.

BTW- I did get through the series today, and did not discover any
issues.  However, I want to sleep on it before signing off.

Muchun Song June 15, 2021, 5:37 a.m. UTC | #3

On Tue, Jun 15, 2021 at 11:52 AM Mike Kravetz <[e-mail]> wrote:
>
> On 6/14/21 6:12 PM, Andrew Morton wrote:
> > On Sat, 12 Jun 2021 17:45:52 +0800 Muchun Song <[e-mail]> 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. When HugeTLB pages are freed from
> >> the pool we do not attempt coalasce and move back to a PMD mapping because
> >> it is much more complex.
> >>
> >> [1] https://lore.kernel.org/linux-doc/[e-mail]/
> >
> > [1] had a nice [0/n] description but the v2 series lost that.  I could
> > copy/paste the v1 changelogging but I am unsure that it has been
> > maintained appropriately for the v2 series.
> >
> > I think I'll pass on this v2 pending additional review input.  Please reinstate
> > the [0/n] overview if/when resending?
>
> There may be some confusion.
>
> This series is a follow on optimization for the functionality provided by
> [1].  Early in the development of [1], it was decided to drop some code
> for ease of review.  Specifically, splitting vmemmap PMD mappings to PTE
> mappings as required when hugetlb pages were allocated.  The
> 'simplification' in [1] is that if the feature is enabled then vmemmap
> will only be mapped with PTEs.
>
> This series provides the ability to split PMD mappings 'on demand' as
> hugetlb pages are allocated.  As mentioned, it really is a follow on and
> optimization to functionality provided in [1].  As such, I am not sure
> that repeating the [0/n] description from 1 is necessary here.
>
> In any case, this should be clearly stated in the [0/n] description of
> this series.

Thanks for the clarification for me. I totally agree with you.

>
> BTW- I did get through the series today, and did not discover any
> issues.  However, I want to sleep on it before signing off.
> --
> Mike Kravetz