| Message ID | 20200915125947.26204-4-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm/hugetlb: Free some vmemmap pages of hugetlb page | expand |
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@bytedance.com> > --- > 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 structures > + page. But we only use a few struct page structure. In this case, structures. > + it waste some memory. It is better to free the unused struct page it wastes > + structures to buddy system which can save some memory. For > + architectures that support it, say Y here. > + > + If unsure, say N. > + > config MEMFD_CREATE > def_bool TMPFS || HUGETLBFS > >
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@bytedance.com> > --- > 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. Also, it looks like most of your development was done on x86. Should this option be limited to x86 only for now?
On Wed, Sep 30, 2020 at 7:41 AM Mike Kravetz <mike.kravetz@oracle.com> 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@bytedance.com> > > --- > > 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
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. + config MEMFD_CREATE def_bool TMPFS || HUGETLBFS
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@bytedance.com> --- fs/Kconfig | 15 +++++++++++++++ 1 file changed, 15 insertions(+)