On 1/15/21 2:16 AM, Oscar Salvador wrote:
> On Mon, Jan 11, 2021 at 01:01:52PM -0800, Mike Kravetz wrote:
>> Use new hugetlb specific flag HPageTempSurplus to replace the
>> PageHugeTemporary() interfaces.
>>
>> Signed-off-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
>> ---
>> mm/hugetlb.c | 38 +++++++++-----------------------------
>> 1 file changed, 9 insertions(+), 29 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 34ce82f4823c..949e1f987319 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -58,6 +58,7 @@ static unsigned long hugetlb_cma_size __initdata;
>> enum htlb_page_flags {
>> HPAGE_RestoreReserve = 0,
>> HPAGE_Migratable,
>> + HPAGE_TempSurplus,
>> };
>>
>> /*
>> @@ -99,6 +100,7 @@ void ClearHPage##flname(struct page *page) \
>>
>> HPAGEFLAG(RestoreReserve)
>> EXT_HPAGEFLAG(Migratable)
>> +HPAGEFLAG(TempSurplus)
>
> Would HPAGE_Temporary/Temporary not be a better fit?
Yes it would.
> The point about current PageHugeTemporary is that these pages are temporary as
> they do not belong to the pool and will vanish once the last reference gets drop.
> We do not really care that much about the surplus part?
>
> Besides, alloc_migrate_huge_page seems to not want to thread these pages as surplus.
>
All correct, not sure why I was thinking 'surplus' when naming the flag.
> Also, I would add a comment either next to each flag or above
> the enum htlb_page_flags (probably the latter) with a brief explanation
> of each flag.
Will do.
--
Mike Kravetz
> Besides that, it looks fine to me.
> Here I do not see the same problem in
> stripping the PageHuge check in PageHugeTemporary, as I did in previous patch,
> because all callers of it make sure they operate on a hugetlb page.
>
