Messages in this thread | | | Subject | Re: [PATCH v2 04/19] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate | From | Mike Kravetz <> | Date | Tue, 27 Oct 2020 15:03:30 -0700 |
| |
On 10/26/20 7:50 AM, Muchun Song wrote: > If the size of hugetlb page is 2MB, we need 512 struct page structures > (8 pages) to be associated with it. As far as I know, we only use the > first 4 struct page structures.
Use of first 4 struct page structures comes from HUGETLB_CGROUP_MIN_ORDER. You could point that out here.
I thought about creating a HUGETLB_MIN_ORDER definition that could be used to calculate RESERVE_VMEMMAP_NR. However, I think a hard coded value of 2U as in the patch is OK.
> For tail pages, the value of compound_dtor is the same. So we can reuse > first page of tail page structs. We map the virtual addresses of the > remaining 6 pages of tail page structs to the first tail page struct, > and then free these 6 pages. Therefore, we need to reserve at least 2 > pages as vmemmap areas. > > So we introduce a new nr_free_vmemmap_pages field in the hstate to > indicate how many vmemmap pages associated with a hugetlb page that we > can free to buddy system. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > include/linux/hugetlb.h | 3 +++ > mm/hugetlb.c | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 38 insertions(+)
Patch looks fine with updated commit message. Acked-by: Mike Kravetz <mike.kravetz@oracle.com>
-- Mike Kravetz
| |