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

[Mike Kravetz]

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