lkml.org 
[lkml]   [2020]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 04/19] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate
From
Date
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

\
 
 \ /
  Last update: 2020-10-27 23:07    [W:0.255 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site