On Wed, Sep 30, 2020 at 7:41 AM Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote: > > On 9/15/20 5:59 AM, Muchun Song wrote: > > The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure > > whether to enable the feature of freeing unused vmemmap associated > > with HugeTLB pages. > > > > Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx> > > --- > > fs/Kconfig | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/fs/Kconfig b/fs/Kconfig > > index 976e8b9033c4..61e9c08096ca 100644 > > --- a/fs/Kconfig > > +++ b/fs/Kconfig > > @@ -245,6 +245,21 @@ config HUGETLBFS > > config HUGETLB_PAGE > > def_bool HUGETLBFS > > > > +config HUGETLB_PAGE_FREE_VMEMMAP > > + bool "Free unused vmemmap associated with HugeTLB pages" > > + default n > > + depends on HUGETLB_PAGE > > + depends on SPARSEMEM_VMEMMAP > > + depends on HAVE_BOOTMEM_INFO_NODE > > + help > > + There are many struct page structure associated with each HugeTLB > > + page. But we only use a few struct page structure. In this case, > > + it waste some memory. It is better to free the unused struct page > > + structures to buddy system which can save some memory. For > > + architectures that support it, say Y here. > > + > > + If unsure, say N. > > + > > I could be wrong, but I believe the convention is introduce the config > option at the same time code which depends on the option is introduced. > Therefore, it might be better to combine with the next patch. Yeah, great. Will do that. Thanks. > > Also, it looks like most of your development was done on x86. Should > this option be limited to x86 only for now? Now only the x86 has the HAVE_BOOTMEM_INFO_NODE option. So maybe this is enough :) > -- > Mike Kravetz -- Yours, Muchun
