| Message ID | 20201026145114.59424-5-songmuchun@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Free some vmemmap pages of hugetlb page | expand |
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>
On Mon, Oct 26, 2020 at 10:50:59PM +0800, 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. As Mike pointed out, better describe what those "4" mean. > For tail pages, the value of compound_dtor is the same. So we can reuse I might be missing something, but HUGETLB_PAGE_DTOR is only set on the first tail, right? > +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP > +#define RESERVE_VMEMMAP_NR 2U Although you can get that from the changelog, maybe a brief comment explaining why RESERVE_VMEMMAP_NR == 2. > + > +static inline unsigned int nr_free_vmemmap(struct hstate *h) > +{ > + return h->nr_free_vmemmap_pages; > +} Better add this in the patch that is used? > + if (vmemmap_pages > RESERVE_VMEMMAP_NR) > + h->nr_free_vmemmap_pages = vmemmap_pages - RESERVE_VMEMMAP_NR; > + else > + h->nr_free_vmemmap_pages = 0; Can we really have an scenario where we end up with vmemmap_pages < RESERVE_VMEMMAP_NR? > + > + pr_info("HugeTLB: can free %d vmemmap pages for %s\n", > + h->nr_free_vmemmap_pages, h->name); I do not think this is useful unless debugging situations, so I would either scratch that or make it pr_debug.
On Thu, Oct 29, 2020 at 9:26 PM Oscar Salvador <osalvador@suse.de> wrote: > > On Mon, Oct 26, 2020 at 10:50:59PM +0800, 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. > > As Mike pointed out, better describe what those "4" mean. Yeah, thanks. > > > For tail pages, the value of compound_dtor is the same. So we can reuse > > I might be missing something, but HUGETLB_PAGE_DTOR is only set on the > first tail, right? Sorry for confusion. Here I mean the `compound_head` is the same. > > > +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP > > +#define RESERVE_VMEMMAP_NR 2U > > Although you can get that from the changelog, maybe a brief comment explaining > why RESERVE_VMEMMAP_NR == 2. > > + > > +static inline unsigned int nr_free_vmemmap(struct hstate *h) > > +{ > > + return h->nr_free_vmemmap_pages; > > +} > > Better add this in the patch that is used? OK, I will do it. thanks. > > > + if (vmemmap_pages > RESERVE_VMEMMAP_NR) > > + h->nr_free_vmemmap_pages = vmemmap_pages - RESERVE_VMEMMAP_NR; > > + else > > + h->nr_free_vmemmap_pages = 0; > > Can we really have an scenario where we end up with vmemmap_pages < RESERVE_VMEMMAP_NR? I think that this is impossible. On the safe side, I do this comparison. Do you think we should remove this comparison? Is that right? > > > + > > + pr_info("HugeTLB: can free %d vmemmap pages for %s\n", > > + h->nr_free_vmemmap_pages, h->name); > > I do not think this is useful unless debugging situations, so I would either > scratch that or make it pr_debug. Thanks for your suggestions. > > > -- > Oscar Salvador > SUSE L3
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index d5cc5f802dd4..eed3dd3bd626 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -492,6 +492,9 @@ struct hstate { unsigned int nr_huge_pages_node[MAX_NUMNODES]; unsigned int free_huge_pages_node[MAX_NUMNODES]; unsigned int surplus_huge_pages_node[MAX_NUMNODES]; +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP + unsigned int nr_free_vmemmap_pages; +#endif #ifdef CONFIG_CGROUP_HUGETLB /* cgroup control files */ struct cftype cgroup_files_dfl[7]; diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 81a41aa080a5..f1b2b733b49b 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1292,6 +1292,39 @@ static inline void destroy_compound_gigantic_page(struct page *page, unsigned int order) { } #endif +#ifdef CONFIG_HUGETLB_PAGE_FREE_VMEMMAP +#define RESERVE_VMEMMAP_NR 2U + +static inline unsigned int nr_free_vmemmap(struct hstate *h) +{ + return h->nr_free_vmemmap_pages; +} + +static void __init hugetlb_vmemmap_init(struct hstate *h) +{ + unsigned int order = huge_page_order(h); + unsigned int vmemmap_pages; + + vmemmap_pages = ((1 << order) * sizeof(struct page)) >> PAGE_SHIFT; + /* + * The head page and the first tail page not free to buddy system, + * the others page will map to the first tail page. So there are + * (@vmemmap_pages - RESERVE_VMEMMAP_NR) pages can be freed. + */ + if (vmemmap_pages > RESERVE_VMEMMAP_NR) + h->nr_free_vmemmap_pages = vmemmap_pages - RESERVE_VMEMMAP_NR; + else + h->nr_free_vmemmap_pages = 0; + + pr_info("HugeTLB: can free %d vmemmap pages for %s\n", + h->nr_free_vmemmap_pages, h->name); +} +#else +static inline void hugetlb_vmemmap_init(struct hstate *h) +{ +} +#endif + static void update_and_free_page(struct hstate *h, struct page *page) { int i; @@ -3285,6 +3318,8 @@ void __init hugetlb_add_hstate(unsigned int order) snprintf(h->name, HSTATE_NAME_LEN, "hugepages-%lukB", huge_page_size(h)/1024); + hugetlb_vmemmap_init(h); + parsed_hstate = h; }
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. 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(+)