On 05.05.22 19:25, Peter Xu wrote: > On Thu, May 05, 2022 at 10:00:07AM -0700, Mike Kravetz wrote: >> Gigantic pages can only be migrated IF there is another (already allocated) >> gigantic page available. The routine to try and allocate a page 'on the fly' >> for migration will fail if passed a gigantic size. There 'might' be a free >> pre-allocated gigantic page. However, if the user set up CMA reserves for >> gigantic page allocations it is likely the free gigantic page is also in CMA. >> Therefore, it can not be used for this migration. So, unless my reasoning >> is wrong, FOLL_LONGTERM would almost always fail for gigantic pages in CMA. > > I'm probably not familiar enough with CMA, but.. I just noticed that if CMA > is destined to not be able to be pinned then maybe it'll lose quite a few > scenarios where pinning is a possible use case. It doesn't even need to be > the major use case, but as long as it's possible (e.g. hypervisors hosting > virtual machines with device assignment) it'll be a hard no to CMA, which > seems to be a pity. > Well, the same applies to ZONE_MOVABLE as well, unfortunately. Eventually, we might want to disable placing hugetlb pages on CMA areas if it turns out to be a problem. In case of ZONE_MOVABLE we can already fail "gracefully" when trying offlining (although that's really far from beautiful). -- Thanks, David / dhildenb
