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
| ||
|
Date: Wed, 16 Dec 2020 11:52:50 +0800 From: Muchun Song <songmuchun@...edance.com> To: Mike Kravetz <mike.kravetz@...cle.com> Cc: Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>, mingo@...hat.com, bp@...en8.de, x86@...nel.org, hpa@...or.com, dave.hansen@...ux.intel.com, luto@...nel.org, Peter Zijlstra <peterz@...radead.org>, viro@...iv.linux.org.uk, Andrew Morton <akpm@...ux-foundation.org>, paulmck@...nel.org, mchehab+huawei@...nel.org, pawan.kumar.gupta@...ux.intel.com, Randy Dunlap <rdunlap@...radead.org>, oneukum@...e.com, anshuman.khandual@....com, jroedel@...e.de, Mina Almasry <almasrymina@...gle.com>, David Rientjes <rientjes@...gle.com>, Matthew Wilcox <willy@...radead.org>, Oscar Salvador <osalvador@...e.de>, Michal Hocko <mhocko@...e.com>, "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>, David Hildenbrand <david@...hat.com>, Xiongchun duan <duanxiongchun@...edance.com>, linux-doc@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, Linux Memory Management List <linux-mm@...ck.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org> Subject: Re: [External] Re: [PATCH v9 02/11] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP On Wed, Dec 16, 2020 at 11:45 AM Mike Kravetz <mike.kravetz@...cle.com> wrote: > > On 12/15/20 5:03 PM, Mike Kravetz wrote: > > On 12/13/20 7:45 AM, Muchun Song wrote: > >> 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. > > Sorry, I am slowly coming up to speed with discussions when I was away. > > It appears vmemmap is not being mapped with huge pages if the boot option > hugetlb_free_vmemmap is on. Is that correct? Right. > > If that is correct, we should document the trade off of increased page > table pages needed to map vmemmap vs the savings from freeing struct page > pages. If a user/sysadmin only uses a small number of hugetlb pages (as > a percentage of system memory) they could end up using more memory with > hugetlb_free_vmemmap on as opposed to off. Perhaps, it should be part of > the documentation for hugetlb_free_vmemmap? If this is true, and people Right, it is better to document it around hugetlb_free_vmemmap. This should be a part of pathe #8. Thanks. > think this should be documented, I can try to come up with something. > > -- > Mike Kravetz -- Yours, Muchun
Powered by blists - more mailing lists