From: Muchun Song <songmuchun@bytedance.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: Xiongchun duan <duanxiongchun@bytedance.com>,
fam.zheng@bytedance.com, linux-doc@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Chen Huang <chenhuang5@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>,
"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
David Hildenbrand <david@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
"Bodeddula, Balasubramaniam" <bodeddub@amazon.com>
Subject: Re: [External] Re: [PATCH v2 3/3] mm: hugetlb: introduce CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON
Date: Wed, 16 Jun 2021 11:04:37 +0800 [thread overview]
Message-ID: <CAMZfGtUPbGRO6fNgRkkGWgUDGgRY3-ijsV6ur=VfnDc9baV2Cg@mail.gmail.com> (raw)
In-Reply-To: <3fffaa5e-246e-00bf-5972-54eeb6330a43@oracle.com>
On Wed, Jun 16, 2021 at 7:01 AM Joao Martins <joao.m.martins@oracle.com> wrote:
>
>
>
> On 6/12/21 10:45 AM, Muchun Song wrote:
> > When using HUGETLB_PAGE_FREE_VMEMMAP, the freeing unused vmemmap pages
> > associated with each HugeTLB page is default off. Now the vmemmap is PMD
> > mapped. So there is no side effect when this feature is enabled with no
> > HugeTLB pages in the system. Someone may want to enable this feature in
> > the compiler time instead of using boot command line. So add a config to
> > make it default on when someone do not want to enable it via command line.
> >
> > Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> > ---
> > Documentation/admin-guide/kernel-parameters.txt | 3 +++
> > fs/Kconfig | 10 ++++++++++
> > mm/hugetlb_vmemmap.c | 6 ++++--
> > 3 files changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index a01aadafee38..8eee439d943c 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -1604,6 +1604,9 @@
> > on: enable the feature
> > off: disable the feature
> >
> > + Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y,
> > + the default is on.
> > +
> > This is not compatible with memory_hotplug.memmap_on_memory.
> > If both parameters are enabled, hugetlb_free_vmemmap takes
> > precedence over memory_hotplug.memmap_on_memory.
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index f40b5b98f7ba..e78bc5daf7b0 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -245,6 +245,16 @@ config HUGETLB_PAGE_FREE_VMEMMAP
> > depends on X86_64
> > depends on SPARSEMEM_VMEMMAP
> >
> Now that you have no longer have the directmap in basepages limitation, I suppose you no
> longer need explicit arch support for HUGETLB_PAGE_FREE_VMEMMAP right?
>
> If so, I suppose you might be able to remove the 'depends on X86_64' part and "gain"
> ARM64, PPC, etc support.
You are right. This is the next step I want to do. Also, include IA64 and RISCV.
>
> Joao
next prev parent reply other threads:[~2021-06-16 3:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-12 9:45 [PATCH v2 0/3] Split huge PMD mapping of vmemmap pages Muchun Song
2021-06-12 9:45 ` [PATCH v2 1/3] mm: sparsemem: split the " Muchun Song
2021-06-15 22:31 ` Mike Kravetz
2021-06-16 3:23 ` [External] " Muchun Song
2021-06-12 9:45 ` [PATCH v2 2/3] mm: sparsemem: use huge PMD mapping for " Muchun Song
2021-06-12 9:45 ` [PATCH v2 3/3] mm: hugetlb: introduce CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON Muchun Song
2021-06-15 23:00 ` Joao Martins
2021-06-16 3:04 ` Muchun Song [this message]
2021-06-15 1:12 ` [PATCH v2 0/3] Split huge PMD mapping of vmemmap pages Andrew Morton
2021-06-15 3:52 ` Mike Kravetz
2021-06-15 5:37 ` [External] " Muchun Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMZfGtUPbGRO6fNgRkkGWgUDGgRY3-ijsV6ur=VfnDc9baV2Cg@mail.gmail.com' \
--to=songmuchun@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=bodeddub@amazon.com \
--cc=chenhuang5@huawei.com \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=duanxiongchun@bytedance.com \
--cc=fam.zheng@bytedance.com \
--cc=joao.m.martins@oracle.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=osalvador@suse.de \
--cc=song.bao.hua@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.