On 3/10/21 8:46 AM, Zi Yan wrote: > The high level goal of this patchset seems to enable flexible huge page > allocation from a single pool, when multiple huge page sizes are available > to use. The limitation of existing mechanism is that user has to specify > how many huge pages he/she wants and how many gigantic pages he/she wants > before the actual use. > > I just want to throw an idea here, please ignore if it is too crazy. > Could we have a variant buddy allocator for huge page allocations, > which only has available huge page orders in the free list? For example, > if user wants 2MB and 1GB pages, the allocator will only have order-9 and > order-19 pages; when order-9 pages run out, we can split order-19 pages; > if possible, adjacent order-9 pages can be merged back to order-19 pages. The idea is not crazy, but I think it is more functionality than we want to throw at hugetlb. IIRC, the default qemu huge page configuration uses THP. Ideally, we would have support for 1G THP pages and the user would not need to think about any of this. The kernel would back the VM with huge pages of the appropriate size for best performance. That may sound crazy, but I think it may be the looooong term goal. -- Mike Kravetz
