>>>>>> It should also be noted that hugetlb code sets up the CMA area from which
>>>>>> hugetlb pages can be allocated. This area is never unreserved/freed.
>>>>>>
>>>>>> I do not think there is a reason to disallow long term pinning of hugetlb
>>>>>> pages allocated from THE hugetlb CMA area.
>>
>> Hm. We primarily use CMA for gigantic pages only IIRC. Ordinary huge
>> pages come via the buddy.
>>
>> Assume we allocated a (movable) 2MiB huge page ordinarily via the buddy
>> and it ended up on that CMA area by pure luck (as it's movable). If we'd
>> allow to pin it long-term, allocating a gigantic page from the
>> designated CMA area would fail.
>
> If we allow the longterm pin against the hugetlb page come via buddy,
> it should be migrated out of CMA before the longterm pinning by
> check_and_migrate_movable_pages, IIUC.
Yes.
> If so, what the allocating a giganitc page from the designated CMA area
> would fail?
Nothing I just summarized it.
>
>>
>> So we'd want to allow long-term pinning a gigantic page but we'd not
>> want to allow long-term pinning an ordinary huge page. We'd want to
>> migrate the latter away.
>
> Sure. Gigantic page was already CMA claimed page so there is no user
> in the future to claim the memory again so fine to allow longterm pin
> but ordinary huge page shouldn't be allowed since CMA owner could
> claim the memory some day.
>
Right.
>>
>>
>> The general rules are:
>>
>> ZONE_MOVABLE: nobody is allowed to place unmovable allocations there; it
>> could prevent memory offlining/unplug.
>>
>> CMA: nobody *but the designated owner* is allowed to place unmovable
>> memory there; it could prevent the actual owner to allocate contiguous
>> memory.
>
> I am confused what's the meaning of designated owner and actuall owner
> in your context.
designated==actual here. I just wanted to distinguish from someone
current temporary owner of the page ("allocated it via a movable
allocation") but the actual designated owner (e.g., hugetlb CMA)
The page/memory owner terminology is just confusing. Let's rephrase to:
only the CMA area owner is allowed to place unmovable allocations there.
>
> What I thought about the issue based on you explanation:
>
> HugeTLB allocates its page by two types of allocation
>
> 1. alloc_pages(GFP_MOVABLE)
>
> It could allocate the hugetlb page from CMA area but longterm pin
> should migrate them out of cma before the pinning so allowing
> the pinning on the page is no problem and current code works like
> that.
>
> check_and_migrate_movable_pages
>
Yes.
> 2. cma_alloc
>
> The cma_alloc is used only for *gigantic page* and the hugetlbfs
> is the very owner of the page. IOW, if the hugetlbfs was succeeded
> to allocate the gigantic page by cma_alloc, there is no other
> owner to be able to claim the page any longer so it's fine to
> allow longterm pinning againt the gingantic page but current.
> However, current code doesn't work like that due to
> is_pinnable_page. IOW, hugetlbfs need a way to distinguish
> whether the page owner is hugetlbfs or not.
>
> Are we on same page?
Yes, exactly. What I wanted to express is: for huge pages we have to
make a smarter decision because there are cases where we want to
migrate, and cases where we don't want to migrate.
--
Thanks,
David / dhildenb
