Messages in this thread | | | Subject | Re: [PATCH v2 2/4] hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA | From | Mike Kravetz <> | Date | Wed, 29 Sep 2021 12:42:05 -0700 |
| |
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
| |