hugetlbfs内存释放

直到最近才发现，如果我们用private映射去申请hugetlbfs的内存，那么内存会在unmap的时候还给操作系统，如果我们通过shared映射去申请hugetlbfs的内存，那么内存会在相应hugetlbfs文件被删除的时候还给操作系统，很好奇这是怎么做到的，于是乎去看了看代码。
以下分析基于linux内核4.19.195.
我们知道，hugetlbfs的内存分配是在hugetlb_fault函数中进行的，最终会调用到函数hugetlb_no_page。

static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
			struct vm_area_struct *vma,
			struct address_space *mapping, pgoff_t idx,
			unsigned long address, pte_t *ptep, unsigned int flags)
{
		******
		if (vma->vm_flags & VM_MAYSHARE) { //如果是共享映射
			int err = huge_add_to_page_cache(page, mapping, idx); //加入radixtree以便共享
			if (err) {
				put_page(page);
				if (err == -EEXIST)
					goto retry;
				goto out;
			}
		} else { //私有映射;注意这里私有映射并不会把page加入radixtree
			lock_page(page);
			if (unlikely(anon_vma_prepare(vma))) {
				ret = VM_FAULT_OOM;
				goto backout_unlocked;
			}
			anon_rmap = 1;
		}
		******

从函数中我们可以看到，hugetlbfs对于共享映射以及private映射的实现是有区分的，共享映射时，会把相关的内存页加入到radix tree里面，而private映射则不会加入到radix tree里。若加入radix tree里，则相关page的引用计数值会加一。

接下来我们来看hugetlbfs内存页的unmap流程，最终会调用到函数__unmap_hugepage_range()完成unmap操作。

void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
			    unsigned long start, unsigned long end,
			    struct page *ref_page)
{
	*****
	address = start;
	for (; address < end; address += sz) {
		******

		page = pte_page(pte);

		pte = huge_ptep_get_and_clear(mm, address, ptep);
		tlb_remove_huge_tlb_entry(h, tlb, ptep, address);
		if (huge_pte_dirty(pte))
			set_page_dirty(page);

		hugetlb_count_sub(pages_per_huge_page(h), mm);
		page_remove_rmap(page, true);

		spin_unlock(ptl);
		tlb_remove_page_size(tlb, page, huge_page_size(h));
		/*
		 * Bail out after unmapping reference page if supplied
		 */
		if (ref_page)
			break;
	}
	mmu_notifier_invalidate_range_end(mm, mmun_start, mmun_end);
	tlb_end_vma(tlb, vma);
}

无论是private映射还是shared映射的内存页，都会走这个流程，最终会完成相关page的put_page操作。结合先前的分析，private映射的页会在这个流程中就被释放掉了，而shared映射的页，由于加入radix tree时将引用计数又加了一，故这个流程里面不会被释放，而是在删除hugetlbfs文件的时候，从radix tree里面删除的时候才把相关内存页释放。