Re: [PATCH v2 04/19] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate

From: Mike Kravetz
Date: Tue Oct 27 2020 - 18:06:06 EST


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@xxxxxxxxxxxxx>
> ---
> 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@xxxxxxxxxx>

--
Mike Kravetz