Messages in this thread | | | Subject | Re: [PATCH v3 1/5] mm,memory_hotplug: Allocate memmap from the added memory range | From | David Hildenbrand <> | Date | Mon, 8 Mar 2021 15:06:49 +0100 |
| |
On 08.03.21 15:04, Oscar Salvador wrote: > On Sun, Mar 07, 2021 at 10:16:36PM -0500, Zi Yan wrote: >> +Mike for hugetlb discussion. >> >> Just thinking about how it might impact gigantic page allocation like hugetlb. >> When MHP_MEMMAP_ON_MEMORY is on, memmap pages are placed at the beginning >> of each hot added memory block, so available PFNs from two consecutive >> hot added memory blocks are not all contiguous, separated by memmap pages. >> If the memory block size is <= 1GB, there is no way of reserving gigantic >> pages for hugetlb during runtime using alloc_contig_pages from any hot >> added memory. Am I getting this right? > > Yes, that is why it is stated both in boot parameter documentation and > patch changelog that this feature does not play well in those setups > where your workload is in need of large contiguous chunks of memory, > that being gigantic hugetlb or just normal memory. > >> I see this implication is documented at the high level in patch 3. Just >> wonder if we want to be more specific. Or hugetlb is rarely used along >> with hot-add memory. > > I think it is quite normal to see hugetlb and hotplug operations in the > same environment. > One thing excludes the other, just need to be careful when it comes to > potential pitfalls during offline operations. > > I guess we could mention hugetlb pages in the documentation, if it feels > it is necesary.
Runtime allocation of gigantic pages without CMA is absolutely unreliable either way. IMHO, a tunable for the admin is good enough.
-- Thanks,
David / dhildenb
| |