On 9/24/21 2:36 AM, David Hildenbrand wrote: > On 23.09.21 19:53, Mike Kravetz wrote: >> When huge page demotion is fully implemented, gigantic pages can be >> demoted to a smaller huge page size. For example, on x86 a 1G page >> can be demoted to 512 2M pages. However, gigantic pages can potentially >> be allocated from CMA. If a gigantic page which was allocated from CMA >> is demoted, the corresponding demoted pages needs to be returned to CMA. >> >> In order to track hugetlb pages that need to be returned to CMA, add the >> hugetlb specific flag HPageCma. Flag is set when a huge page is >> allocated from CMA and transferred to any demoted pages. Non-gigantic >> huge page freeing code checks for the flag and takes appropriate action. > > Do we really need that flag or couldn't we simply always try cma_release() and fallback to out ordinary freeing-path? > > IIRC, cma knows exactly if something was allocated via a CMA are and can be free via it. No need for additional tracking usually. > Yes, I think this is possible. Initially, I thought the check for whether pages were part of CMA involved a mutex or some type of locking. But, it really is lightweight. So, should not be in issue calling in every case. I will most likely add a !CMA_CONFIG stub for cma_release() and remove some of the #ifdefs in hugetlb.c Thanks, I will update in next version. -- Mike Kravetz
