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. -- Peter Xu
