| Message ID | 20201130151838.11208-4-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Free some vmemmap pages of hugetlb page | expand |
On 30.11.20 16:18, 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. And this is just for dependency check. Now only > support x86. x86 - i386 and x86-64? (I assume the latter only ;) ) > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > arch/x86/mm/init_64.c | 2 +- > fs/Kconfig | 14 ++++++++++++++ > 2 files changed, 15 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > index 0a45f062826e..0435bee2e172 100644 > --- a/arch/x86/mm/init_64.c > +++ b/arch/x86/mm/init_64.c > @@ -1225,7 +1225,7 @@ static struct kcore_list kcore_vsyscall; > > static void __init register_page_bootmem_info(void) > { > -#ifdef CONFIG_NUMA > +#if defined(CONFIG_NUMA) || defined(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) > int i; > Why does this hunk belong into this patch? Looks like this should go into another patch. > for_each_online_node(i) > diff --git a/fs/Kconfig b/fs/Kconfig > index 976e8b9033c4..4961dd488444 100644 > --- a/fs/Kconfig > +++ b/fs/Kconfig > @@ -245,6 +245,20 @@ config HUGETLBFS > config HUGETLB_PAGE > def_bool HUGETLBFS > > +config HUGETLB_PAGE_FREE_VMEMMAP > + def_bool HUGETLB_PAGE > + depends on X86 > + depends on SPARSEMEM_VMEMMAP > + depends on HAVE_BOOTMEM_INFO_NODE > + help > + When using HUGETLB_PAGE_FREE_VMEMMAP, the system can save up some > + memory from pre-allocated HugeTLB pages when they are not used. > + 6 pages per 2MB HugeTLB page and 4094 per 1GB HugeTLB page. Calculations only apply to 4k base pages, no? (maybe generalize this a bit or mention 4k base pages - I'm pretty sure we'll see the "depends on X86" part fairly soon if this goes upstream)
On Mon, Dec 7, 2020 at 8:19 PM David Hildenbrand <david@redhat.com> wrote: > > On 30.11.20 16:18, 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. And this is just for dependency check. Now only > > support x86. > > x86 - i386 and x86-64? (I assume the latter only ;) ) Yeah, you are right. Only the latter support SPARSEMEM_VMEMMAP. > > > > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > > --- > > arch/x86/mm/init_64.c | 2 +- > > fs/Kconfig | 14 ++++++++++++++ > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > > index 0a45f062826e..0435bee2e172 100644 > > --- a/arch/x86/mm/init_64.c > > +++ b/arch/x86/mm/init_64.c > > @@ -1225,7 +1225,7 @@ static struct kcore_list kcore_vsyscall; > > > > static void __init register_page_bootmem_info(void) > > { > > -#ifdef CONFIG_NUMA > > +#if defined(CONFIG_NUMA) || defined(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) > > int i; > > > > Why does this hunk belong into this patch? Looks like this should go > into another patch. Of course can. But Mike suggests that it is better to use it when introducing a new config. Because this config depends on HAVE_BOOTMEM_INFO_NODE. And register_page_bootmem_info is aimed to register bootmem info. So maybe it is reasonable from this point of view. What is your opinion? > > > for_each_online_node(i) > > diff --git a/fs/Kconfig b/fs/Kconfig > > index 976e8b9033c4..4961dd488444 100644 > > --- a/fs/Kconfig > > +++ b/fs/Kconfig > > @@ -245,6 +245,20 @@ config HUGETLBFS > > config HUGETLB_PAGE > > def_bool HUGETLBFS > > > > +config HUGETLB_PAGE_FREE_VMEMMAP > > + def_bool HUGETLB_PAGE > > + depends on X86 > > + depends on SPARSEMEM_VMEMMAP > > + depends on HAVE_BOOTMEM_INFO_NODE > > + help > > + When using HUGETLB_PAGE_FREE_VMEMMAP, the system can save up some > > + memory from pre-allocated HugeTLB pages when they are not used. > > + 6 pages per 2MB HugeTLB page and 4094 per 1GB HugeTLB page. > > Calculations only apply to 4k base pages, no? No, if the base page is not 4k, we also can free 6 pages. For example: If the base page size is 64k, the PMD huge page size is 512MB. We also can free 6 pages(64k * 6) vmemmap. But maybe I should document this. Thanks. > (maybe generalize this a > bit or mention 4k base pages - I'm pretty sure we'll see the "depends on > X86" part fairly soon if this goes upstream) Yeah, it can be easy to adapt to different architectures. :) > > > -- > Thanks, > > David / dhildenb >
On 07.12.20 13:42, Muchun Song wrote: > On Mon, Dec 7, 2020 at 8:19 PM David Hildenbrand <david@redhat.com> wrote: >> >> On 30.11.20 16:18, 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. And this is just for dependency check. Now only >>> support x86. >> >> x86 - i386 and x86-64? (I assume the latter only ;) ) > > Yeah, you are right. Only the latter support SPARSEMEM_VMEMMAP. > >> >>> >>> Signed-off-by: Muchun Song <songmuchun@bytedance.com> >>> --- >>> arch/x86/mm/init_64.c | 2 +- >>> fs/Kconfig | 14 ++++++++++++++ >>> 2 files changed, 15 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c >>> index 0a45f062826e..0435bee2e172 100644 >>> --- a/arch/x86/mm/init_64.c >>> +++ b/arch/x86/mm/init_64.c >>> @@ -1225,7 +1225,7 @@ static struct kcore_list kcore_vsyscall; >>> >>> static void __init register_page_bootmem_info(void) >>> { >>> -#ifdef CONFIG_NUMA >>> +#if defined(CONFIG_NUMA) || defined(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) >>> int i; >>> >> >> Why does this hunk belong into this patch? Looks like this should go >> into another patch. > > Of course can. But Mike suggests that it is better to use it when > introducing a new config. Because this config depends on > HAVE_BOOTMEM_INFO_NODE. And register_page_bootmem_info > is aimed to register bootmem info. So maybe it is reasonable from > this point of view. What is your opinion? > Ah, I see. Maybe mention in the patch description, because the "Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP" part left me clueless. Stumbling over this change only left me rather clueless. >> >>> for_each_online_node(i) >>> diff --git a/fs/Kconfig b/fs/Kconfig >>> index 976e8b9033c4..4961dd488444 100644 >>> --- a/fs/Kconfig >>> +++ b/fs/Kconfig >>> @@ -245,6 +245,20 @@ config HUGETLBFS >>> config HUGETLB_PAGE >>> def_bool HUGETLBFS >>> >>> +config HUGETLB_PAGE_FREE_VMEMMAP >>> + def_bool HUGETLB_PAGE >>> + depends on X86 >>> + depends on SPARSEMEM_VMEMMAP >>> + depends on HAVE_BOOTMEM_INFO_NODE >>> + help >>> + When using HUGETLB_PAGE_FREE_VMEMMAP, the system can save up some >>> + memory from pre-allocated HugeTLB pages when they are not used. >>> + 6 pages per 2MB HugeTLB page and 4094 per 1GB HugeTLB page. >> >> Calculations only apply to 4k base pages, no? > > No, if the base page is not 4k, we also can free 6 pages. > > For example: > > If the base page size is 64k, the PMD huge page size is 512MB. We also Note that 2MB huge pages on arm64 with 64k base pages are possible as well. Also, I think powerpc always has 16MB huge pages, independent of base page sizes.
On Mon, Dec 7, 2020 at 8:47 PM David Hildenbrand <david@redhat.com> wrote: > > On 07.12.20 13:42, Muchun Song wrote: > > On Mon, Dec 7, 2020 at 8:19 PM David Hildenbrand <david@redhat.com> wrote: > >> > >> On 30.11.20 16:18, 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. And this is just for dependency check. Now only > >>> support x86. > >> > >> x86 - i386 and x86-64? (I assume the latter only ;) ) > > > > Yeah, you are right. Only the latter support SPARSEMEM_VMEMMAP. > > > >> > >>> > >>> Signed-off-by: Muchun Song <songmuchun@bytedance.com> > >>> --- > >>> arch/x86/mm/init_64.c | 2 +- > >>> fs/Kconfig | 14 ++++++++++++++ > >>> 2 files changed, 15 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c > >>> index 0a45f062826e..0435bee2e172 100644 > >>> --- a/arch/x86/mm/init_64.c > >>> +++ b/arch/x86/mm/init_64.c > >>> @@ -1225,7 +1225,7 @@ static struct kcore_list kcore_vsyscall; > >>> > >>> static void __init register_page_bootmem_info(void) > >>> { > >>> -#ifdef CONFIG_NUMA > >>> +#if defined(CONFIG_NUMA) || defined(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) > >>> int i; > >>> > >> > >> Why does this hunk belong into this patch? Looks like this should go > >> into another patch. > > > > Of course can. But Mike suggests that it is better to use it when > > introducing a new config. Because this config depends on > > HAVE_BOOTMEM_INFO_NODE. And register_page_bootmem_info > > is aimed to register bootmem info. So maybe it is reasonable from > > this point of view. What is your opinion? > > > > Ah, I see. Maybe mention in the patch description, because the > "Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP" part left me > clueless. Stumbling over this change only left me rather clueless. OK, I will improve the commit log. Thanks. > > >> > >>> for_each_online_node(i) > >>> diff --git a/fs/Kconfig b/fs/Kconfig > >>> index 976e8b9033c4..4961dd488444 100644 > >>> --- a/fs/Kconfig > >>> +++ b/fs/Kconfig > >>> @@ -245,6 +245,20 @@ config HUGETLBFS > >>> config HUGETLB_PAGE > >>> def_bool HUGETLBFS > >>> > >>> +config HUGETLB_PAGE_FREE_VMEMMAP > >>> + def_bool HUGETLB_PAGE > >>> + depends on X86 > >>> + depends on SPARSEMEM_VMEMMAP > >>> + depends on HAVE_BOOTMEM_INFO_NODE > >>> + help > >>> + When using HUGETLB_PAGE_FREE_VMEMMAP, the system can save up some > >>> + memory from pre-allocated HugeTLB pages when they are not used. > >>> + 6 pages per 2MB HugeTLB page and 4094 per 1GB HugeTLB page. > >> > >> Calculations only apply to 4k base pages, no? > > > > No, if the base page is not 4k, we also can free 6 pages. > > > > For example: > > > > If the base page size is 64k, the PMD huge page size is 512MB. We also > > Note that 2MB huge pages on arm64 with 64k base pages are possible as > well. Also, I think powerpc always has 16MB huge pages, independent of > base page sizes. I see now. Now only support x86-64, you are right, I should point out the base page size. When supporting more architectures in the future. We can update the message here. :) Thanks. > > > -- > Thanks, > > David / dhildenb >
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 0a45f062826e..0435bee2e172 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -1225,7 +1225,7 @@ static struct kcore_list kcore_vsyscall; static void __init register_page_bootmem_info(void) { -#ifdef CONFIG_NUMA +#if defined(CONFIG_NUMA) || defined(CONFIG_HUGETLB_PAGE_FREE_VMEMMAP) int i; for_each_online_node(i) diff --git a/fs/Kconfig b/fs/Kconfig index 976e8b9033c4..4961dd488444 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -245,6 +245,20 @@ config HUGETLBFS config HUGETLB_PAGE def_bool HUGETLBFS +config HUGETLB_PAGE_FREE_VMEMMAP + def_bool HUGETLB_PAGE + depends on X86 + depends on SPARSEMEM_VMEMMAP + depends on HAVE_BOOTMEM_INFO_NODE + help + When using HUGETLB_PAGE_FREE_VMEMMAP, the system can save up some + memory from pre-allocated HugeTLB pages when they are not used. + 6 pages per 2MB HugeTLB page and 4094 per 1GB HugeTLB page. + + When the pages are going to be used or freed up, the vmemmap array + representing that range needs to be remapped again and the pages + we discarded earlier need to be rellocated again. + 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. And this is just for dependency check. Now only support x86. Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- arch/x86/mm/init_64.c | 2 +- fs/Kconfig | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-)