On Fri, 2020-03-06 at 17:06 -0500, Rik van Riel wrote: > The function pfn_range_valid_contig checks whether all memory in the > target area is free. This causes unnecessary CMA failures, since > alloc_contig_range will migrate movable memory out of a target range, > and has its own sanity check early on in has_unmovable_pages, which > is called from start_isolate_page_range & set_migrate_type_isolate. > > Relying on that has_unmovable_pages call simplifies the CMA code and > results in an increased success rate of CMA allocations. Thinking about this some more, could we get away with entirely removing alloc_contig_pages, and simply having the hugetlb code use cma_alloc? That might be simpler still. It also seems like it could make the success rate of 1GB hugepage allocation much more predictable, because the kernel will place only movable memory allocations inside the CMA area, and we would never try to allocate a 1GB huge page from a 1GB memory area with unmovable pages. It would be possible for the code in hugetlb_init() to invoke the cma setup code as needed, to set aside an appropriate amount of memory for movable allocations (and later CMA 1GB hugepages) only. Then again, if the allocation reliability ends up being eg. 90% instead of 100%, we may need some way to set up the memory pool for CMA hugepage allocation a little larger, and not size it automatically to the desired number of hugepages (with nothing to spare). An explicit hugepage_cma=nG option would cover that. Thoughts? -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
