On 5/20/22 16:43, Minchan Kim wrote: > On Fri, May 20, 2022 at 04:31:31PM -0700, Mike Kravetz wrote: >> On 5/20/22 15:56, John Hubbard wrote: >>> On 5/20/22 15:19, Minchan Kim wrote: >>>> The memory offline would be an issue so we shouldn't allow pinning of any >>>> pages in *movable zone*. >>>> >>>> Isn't alloc_contig_range just best effort? Then, it wouldn't be a big >>>> problem to allow pinning on those area. The matter is what target range >>>> on alloc_contig_range is backed by CMA or movable zone and usecases. >>>> >>>> IOW, movable zone should be never allowed. But CMA case, if pages >>>> are used by normal process memory instead of hugeTLB, we shouldn't >>>> allow longterm pinning since someone can claim those memory suddenly. >>>> However, we are fine to allow longterm pinning if the CMA memory >>>> already claimed and mapped at userspace(hugeTLB case IIUC). >>>> >>> >>> From Mike's comments and yours, plus a rather quick reading of some >>> CMA-related code in mm/hugetlb.c (free_gigantic_page(), alloc_gigantic_pages()), the following seems true: >>> >>> a) hugetlbfs can allocate pages *from* CMA, via cma_alloc() >>> >>> b) while hugetlbfs is using those CMA-allocated pages, it is debatable >>> whether those pages should be allowed to be long term pinned. That's >>> because there are two cases: >>> >>> Case 1: pages are longterm pinned, then released, all while >>> owned by hugetlbfs. No problem. >>> >>> Case 2: pages are longterm pinned, but then hugetlbfs releases the >>> pages entirely (via unmounting hugetlbfs, I presume). In >>> this case, we now have CMA page that are long-term pinned, >>> and that's the state we want to avoid. >> >> I do not think case 2 can happen. A hugetlb page can only be changed back >> to 'normal' (buddy) pages when ref count goes to zero. >> >> 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. >> >> But, I wonder if it is possible for hugetlb pages to be allocated from >> another (non-hugetlb) area. For example if someone sets up a huge CMA area >> and hugetlb allocations spill over into that area. If this is possible >> (still need to research), then we would not want to long term pin such >> hugetlb pages. We can check this in the hugetlb code to determine if >> long term pinning is allowed. > > I don't think it's possible because cma_alloc needs "struct cma" just > like handle and VM doesn't maintain any fallback list of cma chains > so unless someone could steal the handle somehow, there is no way to > claim memory others reserved for the CMA purpose. I was thinking about the case where a hugetlb page is allocated via __alloc_pages(). Not sure if that can fall back to a CMA area that someone else might have created/reserved. Unless I do not understand, normal movable memory allocations can fall back to CMA areas? -- Mike Kravetz
