Re: [PATCH v2 2/4] hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA

From: Mike Kravetz
Date: Wed Sep 29 2021 - 16:26:02 EST


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