linux-kernel - Re: [PATCH v9 02/11] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7cfe44aa-3753-82d9-6630-194f1532e186@oracle.com>
Date:   Tue, 15 Dec 2020 17:03:34 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Muchun Song <songmuchun@...edance.com>, corbet@....net,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        hpa@...or.com, dave.hansen@...ux.intel.com, luto@...nel.org,
        peterz@...radead.org, viro@...iv.linux.org.uk,
        akpm@...ux-foundation.org, paulmck@...nel.org,
        mchehab+huawei@...nel.org, pawan.kumar.gupta@...ux.intel.com,
        rdunlap@...radead.org, oneukum@...e.com, anshuman.khandual@....com,
        jroedel@...e.de, almasrymina@...gle.com, rientjes@...gle.com,
        willy@...radead.org, osalvador@...e.de, mhocko@...e.com,
        song.bao.hua@...ilicon.com, david@...hat.com
Cc:     duanxiongchun@...edance.com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v9 02/11] mm/hugetlb: Introduce a new config
 HUGETLB_PAGE_FREE_VMEMMAP

On 12/13/20 7:45 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. And this is just for dependency check. Now only support
> x86-64.
> 
> Because this config depends on HAVE_BOOTMEM_INFO_NODE. And the function
> of the register_page_bootmem_info() is aimed to register bootmem info.
> So we should register bootmem info when this config is enabled.

Suggested commit message rewording?

The HUGETLB_PAGE_FREE_VMEMMAP option is used to enable the freeing of
unnecessary vmemmap associated with HugeTLB pages.  The config option is
introduced early so that supporting code can be written to depend on the
option.  The initial version of the code only provides support for x86-64.

Like other code which frees vmemmap, this config option depends on
HAVE_BOOTMEM_INFO_NODE.  The routine register_page_bootmem_info() is used
to register bootmem info.  Therefore, make sure register_page_bootmem_info
is enabled if HUGETLB_PAGE_FREE_VMEMMAP is defined.

> 
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
> ---
>  arch/x86/mm/init_64.c |  2 +-
>  fs/Kconfig            | 15 +++++++++++++++
>  2 files changed, 16 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;
>  
>  	for_each_online_node(i)
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 976e8b9033c4..4c3a9c614983 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -245,6 +245,21 @@ config HUGETLBFS
>  config HUGETLB_PAGE
>  	def_bool HUGETLBFS
>  
> +config HUGETLB_PAGE_FREE_VMEMMAP
> +	def_bool HUGETLB_PAGE
> +	depends on X86_64
> +	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 HugeTLB page of the pmd level mapping and (PAGE_SIZE - 2)
> +	  pages per HugeTLB page of the pud level mapping.
> +
> +	  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.

I see the previous discussion with David about wording here.  How about
leaving the functionality description general, and provide a specific
example for x86_64?  As mentioned we can always update when new arch support
is added.  Suggested text?

	The option HUGETLB_PAGE_FREE_VMEMMAP allows for the freeing of
	some vmemmap pages associated with pre-allocated HugeTLB pages.
	For example, on X86_64 6 vmemmap pages of size 4KB each can be
	saved for each 2MB HugeTLB page.  4094 vmemmap pages of size 4KB
	each can be saved for each 1GB HugeTLB page.

	When a HugeTLB page is allocated or freed, the vmemmap array
	representing the range associated with the page will need to be
	remapped.  When a page is allocated, vmemmap pages are freed
	after remapping.  When a page is freed, previously discarded
	vmemmap pages must be allocated before before remapping.

-- 
Mike Kravetz
	
> +
>  config MEMFD_CREATE
>  	def_bool TMPFS || HUGETLBFS
>  
>