On Mon, Dec 7, 2020 at 8:19 PM David Hildenbrand <david@xxxxxxxxxx> 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@xxxxxxxxxxxxx>
> > ---
> > 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
>
--
Yours,
Muchun
