2021-07-01 01:47:13 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
2022-04-29 06:16:14 +00:00
|
|
|
* Optimize vmemmap pages associated with HugeTLB
|
2021-07-01 01:47:13 +00:00
|
|
|
*
|
|
|
|
* Copyright (c) 2020, Bytedance. All rights reserved.
|
|
|
|
*
|
|
|
|
* Author: Muchun Song <songmuchun@bytedance.com>
|
|
|
|
*
|
2022-04-29 06:16:15 +00:00
|
|
|
* See Documentation/vm/vmemmap_dedup.rst
|
2021-07-01 01:47:13 +00:00
|
|
|
*/
|
2021-07-01 01:47:25 +00:00
|
|
|
#define pr_fmt(fmt) "HugeTLB: " fmt
|
|
|
|
|
2021-07-01 01:47:13 +00:00
|
|
|
#include "hugetlb_vmemmap.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There are a lot of struct page structures associated with each HugeTLB page.
|
|
|
|
* For tail pages, the value of compound_head is the same. So we can reuse first
|
mm: hugetlb: free the 2nd vmemmap page associated with each HugeTLB page
Patch series "Free the 2nd vmemmap page associated with each HugeTLB
page", v7.
This series can minimize the overhead of struct page for 2MB HugeTLB
pages significantly. It further reduces the overhead of struct page by
12.5% for a 2MB HugeTLB compared to the previous approach, which means
2GB per 1TB HugeTLB. It is a nice gain. Comments and reviews are
welcome. Thanks.
The main implementation and details can refer to the commit log of patch
1. In this series, I have changed the following four helpers, the
following table shows the impact of the overhead of those helpers.
+------------------+-----------------------+
| APIs | head page | tail page |
+------------------+-----------+-----------+
| PageHead() | Y | N |
+------------------+-----------+-----------+
| PageTail() | Y | N |
+------------------+-----------+-----------+
| PageCompound() | N | N |
+------------------+-----------+-----------+
| compound_head() | Y | N |
+------------------+-----------+-----------+
Y: Overhead is increased.
N: Overhead is _NOT_ increased.
It shows that the overhead of those helpers on a tail page don't change
between "hugetlb_free_vmemmap=on" and "hugetlb_free_vmemmap=off". But the
overhead on a head page will be increased when "hugetlb_free_vmemmap=on"
(except PageCompound()). So I believe that Matthew Wilcox's folio series
will help with this.
The users of PageHead() and PageTail() are much less than compound_head()
and most users of PageTail() are VM_BUG_ON(), so I have done some tests
about the overhead of compound_head() on head pages.
I have tested the overhead of calling compound_head() on a head page,
which is 2.11ns (Measure the call time of 10 million times
compound_head(), and then average).
For a head page whose address is not aligned with PAGE_SIZE or a
non-compound page, the overhead of compound_head() is 2.54ns which is
increased by 20%. For a head page whose address is aligned with
PAGE_SIZE, the overhead of compound_head() is 2.97ns which is increased by
40%. Most pages are the former. I do not think the overhead is
significant since the overhead of compound_head() itself is low.
This patch (of 5):
This patch minimizes the overhead of struct page for 2MB HugeTLB pages
significantly. It further reduces the overhead of struct page by 12.5%
for a 2MB HugeTLB compared to the previous approach, which means 2GB per
1TB HugeTLB (2MB type).
After the feature of "Free sonme vmemmap pages of HugeTLB page" is
enabled, the mapping of the vmemmap addresses associated with a 2MB
HugeTLB page becomes the figure below.
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | -------------> | 1 |
| | +-----------+ +-----------+
| | | 2 | ----------------^ ^ ^ ^ ^ ^
| | +-----------+ | | | | |
| | | 3 | ------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | --------------------+ | | |
| 2MB | +-----------+ | | |
| | | 5 | ----------------------+ | |
| | +-----------+ | |
| | | 6 | ------------------------+ |
| | +-----------+ |
| | | 7 | --------------------------+
| | +-----------+
| |
| |
| |
+-----------+
As we can see, the 2nd vmemmap page frame (indexed by 1) is reused and
remaped. However, the 2nd vmemmap page frame is also can be freed to
the buddy allocator, then we can change the mapping from the figure
above to the figure below.
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | ---------------^ ^ ^ ^ ^ ^ ^
| | +-----------+ | | | | | |
| | | 2 | -----------------+ | | | | |
| | +-----------+ | | | | |
| | | 3 | -------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | ---------------------+ | | |
| 2MB | +-----------+ | | |
| | | 5 | -----------------------+ | |
| | +-----------+ | |
| | | 6 | -------------------------+ |
| | +-----------+ |
| | | 7 | ---------------------------+
| | +-----------+
| |
| |
| |
+-----------+
After we do this, all tail vmemmap pages (1-7) are mapped to the head
vmemmap page frame (0). In other words, there are more than one page
struct with PG_head associated with each HugeTLB page. We __know__ that
there is only one head page struct, the tail page structs with PG_head are
fake head page structs. We need an approach to distinguish between those
two different types of page structs so that compound_head(), PageHead()
and PageTail() can work properly if the parameter is the tail page struct
but with PG_head.
The following code snippet describes how to distinguish between real and
fake head page struct.
if (test_bit(PG_head, &page->flags)) {
unsigned long head = READ_ONCE(page[1].compound_head);
if (head & 1) {
if (head == (unsigned long)page + 1)
==> head page struct
else
==> tail page struct
} else
==> head page struct
}
We can safely access the field of the @page[1] with PG_head because the
@page is a compound page composed with at least two contiguous pages.
[songmuchun@bytedance.com: restore lost comment changes]
Link: https://lkml.kernel.org/r/20211101031651.75851-1-songmuchun@bytedance.com
Link: https://lkml.kernel.org/r/20211101031651.75851-2-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Barry Song <song.bao.hua@hisilicon.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Chen Huang <chenhuang5@huawei.com>
Cc: Bodeddula Balasubramaniam <bodeddub@amazon.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Xiongchun Duan <duanxiongchun@bytedance.com>
Cc: Fam Zheng <fam.zheng@bytedance.com>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-03-22 21:45:00 +00:00
|
|
|
* page of head page structures. We map the virtual addresses of all the pages
|
|
|
|
* of tail page structures to the head page struct, and then free these page
|
|
|
|
* frames. Therefore, we need to reserve one pages as vmemmap areas.
|
2021-07-01 01:47:13 +00:00
|
|
|
*/
|
mm: hugetlb: free the 2nd vmemmap page associated with each HugeTLB page
Patch series "Free the 2nd vmemmap page associated with each HugeTLB
page", v7.
This series can minimize the overhead of struct page for 2MB HugeTLB
pages significantly. It further reduces the overhead of struct page by
12.5% for a 2MB HugeTLB compared to the previous approach, which means
2GB per 1TB HugeTLB. It is a nice gain. Comments and reviews are
welcome. Thanks.
The main implementation and details can refer to the commit log of patch
1. In this series, I have changed the following four helpers, the
following table shows the impact of the overhead of those helpers.
+------------------+-----------------------+
| APIs | head page | tail page |
+------------------+-----------+-----------+
| PageHead() | Y | N |
+------------------+-----------+-----------+
| PageTail() | Y | N |
+------------------+-----------+-----------+
| PageCompound() | N | N |
+------------------+-----------+-----------+
| compound_head() | Y | N |
+------------------+-----------+-----------+
Y: Overhead is increased.
N: Overhead is _NOT_ increased.
It shows that the overhead of those helpers on a tail page don't change
between "hugetlb_free_vmemmap=on" and "hugetlb_free_vmemmap=off". But the
overhead on a head page will be increased when "hugetlb_free_vmemmap=on"
(except PageCompound()). So I believe that Matthew Wilcox's folio series
will help with this.
The users of PageHead() and PageTail() are much less than compound_head()
and most users of PageTail() are VM_BUG_ON(), so I have done some tests
about the overhead of compound_head() on head pages.
I have tested the overhead of calling compound_head() on a head page,
which is 2.11ns (Measure the call time of 10 million times
compound_head(), and then average).
For a head page whose address is not aligned with PAGE_SIZE or a
non-compound page, the overhead of compound_head() is 2.54ns which is
increased by 20%. For a head page whose address is aligned with
PAGE_SIZE, the overhead of compound_head() is 2.97ns which is increased by
40%. Most pages are the former. I do not think the overhead is
significant since the overhead of compound_head() itself is low.
This patch (of 5):
This patch minimizes the overhead of struct page for 2MB HugeTLB pages
significantly. It further reduces the overhead of struct page by 12.5%
for a 2MB HugeTLB compared to the previous approach, which means 2GB per
1TB HugeTLB (2MB type).
After the feature of "Free sonme vmemmap pages of HugeTLB page" is
enabled, the mapping of the vmemmap addresses associated with a 2MB
HugeTLB page becomes the figure below.
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | -------------> | 1 |
| | +-----------+ +-----------+
| | | 2 | ----------------^ ^ ^ ^ ^ ^
| | +-----------+ | | | | |
| | | 3 | ------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | --------------------+ | | |
| 2MB | +-----------+ | | |
| | | 5 | ----------------------+ | |
| | +-----------+ | |
| | | 6 | ------------------------+ |
| | +-----------+ |
| | | 7 | --------------------------+
| | +-----------+
| |
| |
| |
+-----------+
As we can see, the 2nd vmemmap page frame (indexed by 1) is reused and
remaped. However, the 2nd vmemmap page frame is also can be freed to
the buddy allocator, then we can change the mapping from the figure
above to the figure below.
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | ---------------^ ^ ^ ^ ^ ^ ^
| | +-----------+ | | | | | |
| | | 2 | -----------------+ | | | | |
| | +-----------+ | | | | |
| | | 3 | -------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | ---------------------+ | | |
| 2MB | +-----------+ | | |
| | | 5 | -----------------------+ | |
| | +-----------+ | |
| | | 6 | -------------------------+ |
| | +-----------+ |
| | | 7 | ---------------------------+
| | +-----------+
| |
| |
| |
+-----------+
After we do this, all tail vmemmap pages (1-7) are mapped to the head
vmemmap page frame (0). In other words, there are more than one page
struct with PG_head associated with each HugeTLB page. We __know__ that
there is only one head page struct, the tail page structs with PG_head are
fake head page structs. We need an approach to distinguish between those
two different types of page structs so that compound_head(), PageHead()
and PageTail() can work properly if the parameter is the tail page struct
but with PG_head.
The following code snippet describes how to distinguish between real and
fake head page struct.
if (test_bit(PG_head, &page->flags)) {
unsigned long head = READ_ONCE(page[1].compound_head);
if (head & 1) {
if (head == (unsigned long)page + 1)
==> head page struct
else
==> tail page struct
} else
==> head page struct
}
We can safely access the field of the @page[1] with PG_head because the
@page is a compound page composed with at least two contiguous pages.
[songmuchun@bytedance.com: restore lost comment changes]
Link: https://lkml.kernel.org/r/20211101031651.75851-1-songmuchun@bytedance.com
Link: https://lkml.kernel.org/r/20211101031651.75851-2-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Barry Song <song.bao.hua@hisilicon.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Chen Huang <chenhuang5@huawei.com>
Cc: Bodeddula Balasubramaniam <bodeddub@amazon.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Xiongchun Duan <duanxiongchun@bytedance.com>
Cc: Fam Zheng <fam.zheng@bytedance.com>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-03-22 21:45:00 +00:00
|
|
|
#define RESERVE_VMEMMAP_NR 1U
|
2021-07-01 01:47:13 +00:00
|
|
|
#define RESERVE_VMEMMAP_SIZE (RESERVE_VMEMMAP_NR << PAGE_SHIFT)
|
|
|
|
|
2022-04-29 06:16:15 +00:00
|
|
|
DEFINE_STATIC_KEY_MAYBE(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON,
|
2022-04-29 06:16:15 +00:00
|
|
|
hugetlb_optimize_vmemmap_key);
|
|
|
|
EXPORT_SYMBOL(hugetlb_optimize_vmemmap_key);
|
2021-07-01 01:47:25 +00:00
|
|
|
|
2022-04-29 06:16:14 +00:00
|
|
|
static int __init hugetlb_vmemmap_early_param(char *buf)
|
2021-07-01 01:47:25 +00:00
|
|
|
{
|
2022-05-13 23:48:56 +00:00
|
|
|
bool enable;
|
|
|
|
|
|
|
|
if (kstrtobool(buf, &enable))
|
2021-07-01 01:47:25 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
2022-05-13 23:48:56 +00:00
|
|
|
if (enable)
|
2022-04-29 06:16:15 +00:00
|
|
|
static_branch_enable(&hugetlb_optimize_vmemmap_key);
|
2021-07-01 01:48:28 +00:00
|
|
|
else
|
2022-05-13 23:48:56 +00:00
|
|
|
static_branch_disable(&hugetlb_optimize_vmemmap_key);
|
2021-07-01 01:47:25 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2022-04-29 06:16:14 +00:00
|
|
|
early_param("hugetlb_free_vmemmap", hugetlb_vmemmap_early_param);
|
2021-07-01 01:47:13 +00:00
|
|
|
|
2021-07-01 01:47:21 +00:00
|
|
|
/*
|
|
|
|
* Previously discarded vmemmap pages will be allocated and remapping
|
|
|
|
* after this function returns zero.
|
|
|
|
*/
|
2022-04-29 06:16:14 +00:00
|
|
|
int hugetlb_vmemmap_alloc(struct hstate *h, struct page *head)
|
2021-07-01 01:47:21 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
unsigned long vmemmap_addr = (unsigned long)head;
|
2022-04-29 06:16:14 +00:00
|
|
|
unsigned long vmemmap_end, vmemmap_reuse, vmemmap_pages;
|
2021-07-01 01:47:21 +00:00
|
|
|
|
|
|
|
if (!HPageVmemmapOptimized(head))
|
|
|
|
return 0;
|
|
|
|
|
2022-04-29 06:16:14 +00:00
|
|
|
vmemmap_addr += RESERVE_VMEMMAP_SIZE;
|
|
|
|
vmemmap_pages = hugetlb_optimize_vmemmap_pages(h);
|
|
|
|
vmemmap_end = vmemmap_addr + (vmemmap_pages << PAGE_SHIFT);
|
|
|
|
vmemmap_reuse = vmemmap_addr - PAGE_SIZE;
|
|
|
|
|
2021-07-01 01:47:21 +00:00
|
|
|
/*
|
|
|
|
* The pages which the vmemmap virtual address range [@vmemmap_addr,
|
|
|
|
* @vmemmap_end) are mapped to are freed to the buddy allocator, and
|
|
|
|
* the range is mapped to the page which @vmemmap_reuse is mapped to.
|
|
|
|
* When a HugeTLB page is freed to the buddy allocator, previously
|
|
|
|
* discarded vmemmap pages must be allocated and remapping.
|
|
|
|
*/
|
|
|
|
ret = vmemmap_remap_alloc(vmemmap_addr, vmemmap_end, vmemmap_reuse,
|
|
|
|
GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE);
|
|
|
|
if (!ret)
|
|
|
|
ClearHPageVmemmapOptimized(head);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-04-29 06:16:14 +00:00
|
|
|
void hugetlb_vmemmap_free(struct hstate *h, struct page *head)
|
2021-07-01 01:47:13 +00:00
|
|
|
{
|
|
|
|
unsigned long vmemmap_addr = (unsigned long)head;
|
2022-04-29 06:16:14 +00:00
|
|
|
unsigned long vmemmap_end, vmemmap_reuse, vmemmap_pages;
|
2021-07-01 01:47:13 +00:00
|
|
|
|
2022-04-29 06:16:14 +00:00
|
|
|
vmemmap_pages = hugetlb_optimize_vmemmap_pages(h);
|
|
|
|
if (!vmemmap_pages)
|
2021-07-01 01:47:13 +00:00
|
|
|
return;
|
|
|
|
|
2022-04-29 06:16:14 +00:00
|
|
|
vmemmap_addr += RESERVE_VMEMMAP_SIZE;
|
|
|
|
vmemmap_end = vmemmap_addr + (vmemmap_pages << PAGE_SHIFT);
|
|
|
|
vmemmap_reuse = vmemmap_addr - PAGE_SIZE;
|
2021-07-01 01:47:13 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Remap the vmemmap virtual address range [@vmemmap_addr, @vmemmap_end)
|
|
|
|
* to the page which @vmemmap_reuse is mapped to, then free the pages
|
|
|
|
* which the range [@vmemmap_addr, @vmemmap_end] is mapped to.
|
|
|
|
*/
|
2021-07-01 01:48:22 +00:00
|
|
|
if (!vmemmap_remap_free(vmemmap_addr, vmemmap_end, vmemmap_reuse))
|
|
|
|
SetHPageVmemmapOptimized(head);
|
2021-07-01 01:47:13 +00:00
|
|
|
}
|
2021-07-01 01:47:33 +00:00
|
|
|
|
|
|
|
void __init hugetlb_vmemmap_init(struct hstate *h)
|
|
|
|
{
|
|
|
|
unsigned int nr_pages = pages_per_huge_page(h);
|
|
|
|
unsigned int vmemmap_pages;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There are only (RESERVE_VMEMMAP_SIZE / sizeof(struct page)) struct
|
2022-04-29 06:16:15 +00:00
|
|
|
* page structs that can be used when CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP,
|
2021-07-01 01:47:33 +00:00
|
|
|
* so add a BUILD_BUG_ON to catch invalid usage of the tail struct page.
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(__NR_USED_SUBPAGE >=
|
|
|
|
RESERVE_VMEMMAP_SIZE / sizeof(struct page));
|
|
|
|
|
2022-04-29 06:16:15 +00:00
|
|
|
if (!hugetlb_optimize_vmemmap_enabled())
|
2021-07-01 01:47:33 +00:00
|
|
|
return;
|
|
|
|
|
2022-05-13 23:48:56 +00:00
|
|
|
if (!is_power_of_2(sizeof(struct page))) {
|
|
|
|
pr_warn_once("cannot optimize vmemmap pages because \"struct page\" crosses page boundaries\n");
|
|
|
|
static_branch_disable(&hugetlb_optimize_vmemmap_key);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2021-07-01 01:47:33 +00:00
|
|
|
vmemmap_pages = (nr_pages * sizeof(struct page)) >> PAGE_SHIFT;
|
|
|
|
/*
|
mm: hugetlb: free the 2nd vmemmap page associated with each HugeTLB page
Patch series "Free the 2nd vmemmap page associated with each HugeTLB
page", v7.
This series can minimize the overhead of struct page for 2MB HugeTLB
pages significantly. It further reduces the overhead of struct page by
12.5% for a 2MB HugeTLB compared to the previous approach, which means
2GB per 1TB HugeTLB. It is a nice gain. Comments and reviews are
welcome. Thanks.
The main implementation and details can refer to the commit log of patch
1. In this series, I have changed the following four helpers, the
following table shows the impact of the overhead of those helpers.
+------------------+-----------------------+
| APIs | head page | tail page |
+------------------+-----------+-----------+
| PageHead() | Y | N |
+------------------+-----------+-----------+
| PageTail() | Y | N |
+------------------+-----------+-----------+
| PageCompound() | N | N |
+------------------+-----------+-----------+
| compound_head() | Y | N |
+------------------+-----------+-----------+
Y: Overhead is increased.
N: Overhead is _NOT_ increased.
It shows that the overhead of those helpers on a tail page don't change
between "hugetlb_free_vmemmap=on" and "hugetlb_free_vmemmap=off". But the
overhead on a head page will be increased when "hugetlb_free_vmemmap=on"
(except PageCompound()). So I believe that Matthew Wilcox's folio series
will help with this.
The users of PageHead() and PageTail() are much less than compound_head()
and most users of PageTail() are VM_BUG_ON(), so I have done some tests
about the overhead of compound_head() on head pages.
I have tested the overhead of calling compound_head() on a head page,
which is 2.11ns (Measure the call time of 10 million times
compound_head(), and then average).
For a head page whose address is not aligned with PAGE_SIZE or a
non-compound page, the overhead of compound_head() is 2.54ns which is
increased by 20%. For a head page whose address is aligned with
PAGE_SIZE, the overhead of compound_head() is 2.97ns which is increased by
40%. Most pages are the former. I do not think the overhead is
significant since the overhead of compound_head() itself is low.
This patch (of 5):
This patch minimizes the overhead of struct page for 2MB HugeTLB pages
significantly. It further reduces the overhead of struct page by 12.5%
for a 2MB HugeTLB compared to the previous approach, which means 2GB per
1TB HugeTLB (2MB type).
After the feature of "Free sonme vmemmap pages of HugeTLB page" is
enabled, the mapping of the vmemmap addresses associated with a 2MB
HugeTLB page becomes the figure below.
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | -------------> | 1 |
| | +-----------+ +-----------+
| | | 2 | ----------------^ ^ ^ ^ ^ ^
| | +-----------+ | | | | |
| | | 3 | ------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | --------------------+ | | |
| 2MB | +-----------+ | | |
| | | 5 | ----------------------+ | |
| | +-----------+ | |
| | | 6 | ------------------------+ |
| | +-----------+ |
| | | 7 | --------------------------+
| | +-----------+
| |
| |
| |
+-----------+
As we can see, the 2nd vmemmap page frame (indexed by 1) is reused and
remaped. However, the 2nd vmemmap page frame is also can be freed to
the buddy allocator, then we can change the mapping from the figure
above to the figure below.
HugeTLB struct pages(8 pages) page frame(8 pages)
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+---> PG_head
| | | 0 | -------------> | 0 |
| | +-----------+ +-----------+
| | | 1 | ---------------^ ^ ^ ^ ^ ^ ^
| | +-----------+ | | | | | |
| | | 2 | -----------------+ | | | | |
| | +-----------+ | | | | |
| | | 3 | -------------------+ | | | |
| | +-----------+ | | | |
| | | 4 | ---------------------+ | | |
| 2MB | +-----------+ | | |
| | | 5 | -----------------------+ | |
| | +-----------+ | |
| | | 6 | -------------------------+ |
| | +-----------+ |
| | | 7 | ---------------------------+
| | +-----------+
| |
| |
| |
+-----------+
After we do this, all tail vmemmap pages (1-7) are mapped to the head
vmemmap page frame (0). In other words, there are more than one page
struct with PG_head associated with each HugeTLB page. We __know__ that
there is only one head page struct, the tail page structs with PG_head are
fake head page structs. We need an approach to distinguish between those
two different types of page structs so that compound_head(), PageHead()
and PageTail() can work properly if the parameter is the tail page struct
but with PG_head.
The following code snippet describes how to distinguish between real and
fake head page struct.
if (test_bit(PG_head, &page->flags)) {
unsigned long head = READ_ONCE(page[1].compound_head);
if (head & 1) {
if (head == (unsigned long)page + 1)
==> head page struct
else
==> tail page struct
} else
==> head page struct
}
We can safely access the field of the @page[1] with PG_head because the
@page is a compound page composed with at least two contiguous pages.
[songmuchun@bytedance.com: restore lost comment changes]
Link: https://lkml.kernel.org/r/20211101031651.75851-1-songmuchun@bytedance.com
Link: https://lkml.kernel.org/r/20211101031651.75851-2-songmuchun@bytedance.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Barry Song <song.bao.hua@hisilicon.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Chen Huang <chenhuang5@huawei.com>
Cc: Bodeddula Balasubramaniam <bodeddub@amazon.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Xiongchun Duan <duanxiongchun@bytedance.com>
Cc: Fam Zheng <fam.zheng@bytedance.com>
Cc: Qi Zheng <zhengqi.arch@bytedance.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-03-22 21:45:00 +00:00
|
|
|
* The head page is not to be freed to buddy allocator, the other tail
|
|
|
|
* pages will map to the head page, so they can be freed.
|
2021-07-01 01:47:33 +00:00
|
|
|
*
|
|
|
|
* Could RESERVE_VMEMMAP_NR be greater than @vmemmap_pages? It is true
|
|
|
|
* on some architectures (e.g. aarch64). See Documentation/arm64/
|
|
|
|
* hugetlbpage.rst for more details.
|
|
|
|
*/
|
|
|
|
if (likely(vmemmap_pages > RESERVE_VMEMMAP_NR))
|
2022-04-29 06:16:14 +00:00
|
|
|
h->optimize_vmemmap_pages = vmemmap_pages - RESERVE_VMEMMAP_NR;
|
2021-07-01 01:47:33 +00:00
|
|
|
|
2022-04-29 06:16:14 +00:00
|
|
|
pr_info("can optimize %d vmemmap pages for %s\n",
|
|
|
|
h->optimize_vmemmap_pages, h->name);
|
2021-07-01 01:47:33 +00:00
|
|
|
}
|