linux-kernel - Re: [PATCH v6 4/4] mm: hugetlb_vmemmap: add hugetlb_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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Wed, 30 Mar 2022 19:36:57 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Muchun Song <songmuchun@...edance.com>
Cc:     corbet@....net, mike.kravetz@...cle.com, mcgrof@...nel.org,
        keescook@...omium.org, yzaikin@...gle.com, osalvador@...e.de,
        david@...hat.com, masahiroy@...nel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        duanxiongchun@...edance.com, smuchun@...il.com
Subject: Re: [PATCH v6 4/4] mm: hugetlb_vmemmap: add hugetlb_free_vmemmap
 sysctl

On Wed, 30 Mar 2022 23:37:45 +0800 Muchun Song <songmuchun@...edance.com> wrote:

> We must add "hugetlb_free_vmemmap=on" to boot cmdline and reboot the
> server to enable the feature of freeing vmemmap pages of HugeTLB
> pages.  Rebooting usually takes a long time.  Add a sysctl to enable
> or disable the feature at runtime without rebooting.

I forget, why did we add the hugetlb_free_vmemmap option in the first
place?  Why not just leave the feature enabled in all cases?

Furthermore, why would anyone want to tweak this at runtime?  What is
the use case?  Where is the end-user value in all of this?

> Disabling requires there is no any optimized HugeTLB page in the
> system.  If you fail to disable it, you can set "nr_hugepages" to 0
> and then retry.
> 
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -561,6 +561,20 @@ Change the minimum size of the hugepage pool.
>  See Documentation/admin-guide/mm/hugetlbpage.rst
>  
>  
> +hugetlb_free_vmemmap
> +====================
> +
> +Enable (set to 1) or disable (set to 0) the feature of optimizing vmemmap
> +pages associated with each HugeTLB page.  Once true, the vmemmap pages of
> +subsequent allocation of HugeTLB pages from buddy system will be optimized,
> +whereas already allocated HugeTLB pages will not be optimized.  If you fail
> +to disable this feature, you can set "nr_hugepages" to 0 and then retry
> +since it is only allowed to be disabled after there is no any optimized
> +HugeTLB page in the system.
> +

Pity the poor user who is looking at this and wondering whether it will
improve or worsen things.  If we don't tell them, who will?  Are they
supposed to just experiment?

What can we add here to help them understand whether this might be
beneficial?

> +See Documentation/admin-guide/mm/hugetlbpage.rst