lkml.org 
[lkml]   [2021]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 2/4] hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA
From
Date
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

\
 
 \ /
  Last update: 2021-09-29 22:26    [W:0.099 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site