Re: [External] Re: [PATCH v13 09/12] mm: hugetlb: add a kernel parameter hugetlb_free_vmemmap
From: Muchun Song <hidden>
Date: 2021-01-26 20:13:52
Also in:
linux-doc, linux-fsdevel, lkml
From: Muchun Song <hidden>
Date: 2021-01-26 20:13:52
Also in:
linux-doc, linux-fsdevel, lkml
On Mon, Jan 25, 2021 at 7:43 PM David Hildenbrand [off-list ref] wrote:
On 17.01.21 16:10, Muchun Song wrote:quoted
Add a kernel parameter hugetlb_free_vmemmap to enable the feature of freeing unused vmemmap pages associated with each hugetlb page on boot.The description completely lacks a description of the changes performed in arch/x86/mm/init_64.c.
Will update. Thanks.
[...]quoted
--- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c@@ -34,6 +34,7 @@ #include <linux/gfp.h> #include <linux/kcore.h> #include <linux/bootmem_info.h> +#include <linux/hugetlb.h> #include <asm/processor.h> #include <asm/bios_ebda.h>@@ -1557,7 +1558,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, { int err; - if (end - start < PAGES_PER_SECTION * sizeof(struct page)) + if (is_hugetlb_free_vmemmap_enabled() || + end - start < PAGES_PER_SECTION * sizeof(struct page))This looks irresponsible. You ignore any altmap, even though current altmap users (ZONE_DEVICE) will not actually result in applicable vmemmaps that huge pages could ever use. Why do you ignore the altmap completely? This has to be properly documented, but IMHO it's not even the right approach to mess with altmap here.
Thanks for reminding me of this. Sorry I also did not notice that.
-- Thanks, David / dhildenb