2021-07-01 09:47:13 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
2022-06-28 17:22:30 +08:00
|
|
|
* HugeTLB Vmemmap Optimization (HVO)
|
2021-07-01 09:47:13 +08:00
|
|
|
*
|
2022-06-28 17:22:30 +08:00
|
|
|
* Copyright (c) 2020, ByteDance. All rights reserved.
|
2021-07-01 09:47:13 +08:00
|
|
|
*
|
|
|
|
* Author: Muchun Song <songmuchun@bytedance.com>
|
|
|
|
*
|
2022-06-27 14:00:26 +08:00
|
|
|
* See Documentation/mm/vmemmap_dedup.rst
|
2021-07-01 09:47:13 +08:00
|
|
|
*/
|
2021-07-01 09:47:25 +08:00
|
|
|
#define pr_fmt(fmt) "HugeTLB: " fmt
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
#include <linux/pgtable.h>
|
2022-11-03 02:09:17 +08:00
|
|
|
#include <linux/moduleparam.h>
|
2022-06-28 17:22:31 +08:00
|
|
|
#include <linux/bootmem_info.h>
|
2023-08-30 05:37:34 +08:00
|
|
|
#include <linux/mmdebug.h>
|
2023-11-27 16:46:43 +08:00
|
|
|
#include <linux/pagewalk.h>
|
2022-06-28 17:22:31 +08:00
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/tlbflush.h>
|
2021-07-01 09:47:13 +08:00
|
|
|
#include "hugetlb_vmemmap.h"
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
/**
|
|
|
|
* struct vmemmap_remap_walk - walk vmemmap page table
|
|
|
|
*
|
|
|
|
* @remap_pte: called for each lowest-level entry (PTE).
|
|
|
|
* @nr_walked: the number of walked pte.
|
|
|
|
* @reuse_page: the page which is reused for the tail vmemmap pages.
|
|
|
|
* @reuse_addr: the virtual address of the @reuse_page page.
|
|
|
|
* @vmemmap_pages: the list head of the vmemmap pages that can be freed
|
|
|
|
* or is mapped from.
|
2023-10-19 10:31:08 +08:00
|
|
|
* @flags: used to modify behavior in vmemmap page table walking
|
|
|
|
* operations.
|
2022-06-28 17:22:31 +08:00
|
|
|
*/
|
|
|
|
struct vmemmap_remap_walk {
|
|
|
|
void (*remap_pte)(pte_t *pte, unsigned long addr,
|
|
|
|
struct vmemmap_remap_walk *walk);
|
|
|
|
unsigned long nr_walked;
|
|
|
|
struct page *reuse_page;
|
|
|
|
unsigned long reuse_addr;
|
|
|
|
struct list_head *vmemmap_pages;
|
2023-10-19 10:31:08 +08:00
|
|
|
|
|
|
|
/* Skip the TLB flush when we split the PMD */
|
|
|
|
#define VMEMMAP_SPLIT_NO_TLB_FLUSH BIT(0)
|
2023-10-19 10:31:09 +08:00
|
|
|
/* Skip the TLB flush when we remap the PTE */
|
|
|
|
#define VMEMMAP_REMAP_NO_TLB_FLUSH BIT(1)
|
2023-10-19 10:31:08 +08:00
|
|
|
unsigned long flags;
|
2022-06-28 17:22:31 +08:00
|
|
|
};
|
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
static int vmemmap_split_pmd(pmd_t *pmd, struct page *head, unsigned long start,
|
|
|
|
struct vmemmap_remap_walk *walk)
|
2022-06-28 17:22:31 +08:00
|
|
|
{
|
|
|
|
pmd_t __pmd;
|
|
|
|
int i;
|
|
|
|
unsigned long addr = start;
|
2023-07-07 11:38:59 +08:00
|
|
|
pte_t *pgtable;
|
|
|
|
|
|
|
|
pgtable = pte_alloc_one_kernel(&init_mm);
|
2022-06-28 17:22:31 +08:00
|
|
|
if (!pgtable)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
pmd_populate_kernel(&init_mm, &__pmd, pgtable);
|
|
|
|
|
2022-06-28 17:22:35 +08:00
|
|
|
for (i = 0; i < PTRS_PER_PTE; i++, addr += PAGE_SIZE) {
|
2022-06-28 17:22:31 +08:00
|
|
|
pte_t entry, *pte;
|
|
|
|
pgprot_t pgprot = PAGE_KERNEL;
|
|
|
|
|
2023-07-07 11:38:59 +08:00
|
|
|
entry = mk_pte(head + i, pgprot);
|
2022-06-28 17:22:31 +08:00
|
|
|
pte = pte_offset_kernel(&__pmd, addr);
|
|
|
|
set_pte_at(&init_mm, addr, pte, entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_lock(&init_mm.page_table_lock);
|
|
|
|
if (likely(pmd_leaf(*pmd))) {
|
|
|
|
/*
|
|
|
|
* Higher order allocations from buddy allocator must be able to
|
|
|
|
* be treated as indepdenent small pages (as they can be freed
|
|
|
|
* individually).
|
|
|
|
*/
|
2023-07-07 11:38:59 +08:00
|
|
|
if (!PageReserved(head))
|
|
|
|
split_page(head, get_order(PMD_SIZE));
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
/* Make pte visible before pmd. See comment in pmd_install(). */
|
|
|
|
smp_wmb();
|
|
|
|
pmd_populate_kernel(&init_mm, pmd, pgtable);
|
2023-11-27 16:46:43 +08:00
|
|
|
if (!(walk->flags & VMEMMAP_SPLIT_NO_TLB_FLUSH))
|
2023-10-19 10:31:08 +08:00
|
|
|
flush_tlb_kernel_range(start, start + PMD_SIZE);
|
2022-06-28 17:22:31 +08:00
|
|
|
} else {
|
|
|
|
pte_free_kernel(&init_mm, pgtable);
|
|
|
|
}
|
|
|
|
spin_unlock(&init_mm.page_table_lock);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
static int vmemmap_pmd_entry(pmd_t *pmd, unsigned long addr,
|
|
|
|
unsigned long next, struct mm_walk *walk)
|
2022-06-28 17:22:31 +08:00
|
|
|
{
|
2023-11-27 16:46:44 +08:00
|
|
|
int ret = 0;
|
2023-11-27 16:46:43 +08:00
|
|
|
struct page *head;
|
|
|
|
struct vmemmap_remap_walk *vmemmap_walk = walk->private;
|
2023-10-19 10:31:08 +08:00
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
/* Only splitting, not remapping the vmemmap pages. */
|
|
|
|
if (!vmemmap_walk->remap_pte)
|
|
|
|
walk->action = ACTION_CONTINUE;
|
2023-10-19 10:31:08 +08:00
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
spin_lock(&init_mm.page_table_lock);
|
|
|
|
head = pmd_leaf(*pmd) ? pmd_page(*pmd) : NULL;
|
2023-11-27 16:46:44 +08:00
|
|
|
/*
|
|
|
|
* Due to HugeTLB alignment requirements and the vmemmap
|
|
|
|
* pages being at the start of the hotplugged memory
|
|
|
|
* region in memory_hotplug.memmap_on_memory case. Checking
|
|
|
|
* the vmemmap page associated with the first vmemmap page
|
|
|
|
* if it is self-hosted is sufficient.
|
|
|
|
*
|
|
|
|
* [ hotplugged memory ]
|
|
|
|
* [ section ][...][ section ]
|
|
|
|
* [ vmemmap ][ usable memory ]
|
|
|
|
* ^ | ^ |
|
|
|
|
* +--+ | |
|
|
|
|
* +------------------------+
|
|
|
|
*/
|
2023-12-05 11:05:30 +08:00
|
|
|
if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG) && unlikely(!vmemmap_walk->nr_walked)) {
|
2023-11-27 16:46:44 +08:00
|
|
|
struct page *page = head ? head + pte_index(addr) :
|
|
|
|
pte_page(ptep_get(pte_offset_kernel(pmd, addr)));
|
|
|
|
|
|
|
|
if (PageVmemmapSelfHosted(page))
|
|
|
|
ret = -ENOTSUPP;
|
|
|
|
}
|
2023-11-27 16:46:43 +08:00
|
|
|
spin_unlock(&init_mm.page_table_lock);
|
2023-11-27 16:46:44 +08:00
|
|
|
if (!head || ret)
|
|
|
|
return ret;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
return vmemmap_split_pmd(pmd, head, addr & PMD_MASK, vmemmap_walk);
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
static int vmemmap_pte_entry(pte_t *pte, unsigned long addr,
|
|
|
|
unsigned long next, struct mm_walk *walk)
|
2022-06-28 17:22:31 +08:00
|
|
|
{
|
2023-11-27 16:46:43 +08:00
|
|
|
struct vmemmap_remap_walk *vmemmap_walk = walk->private;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
/*
|
|
|
|
* The reuse_page is found 'first' in page table walking before
|
|
|
|
* starting remapping.
|
|
|
|
*/
|
|
|
|
if (!vmemmap_walk->reuse_page)
|
|
|
|
vmemmap_walk->reuse_page = pte_page(ptep_get(pte));
|
|
|
|
else
|
|
|
|
vmemmap_walk->remap_pte(pte, addr, vmemmap_walk);
|
|
|
|
vmemmap_walk->nr_walked++;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
static const struct mm_walk_ops vmemmap_remap_ops = {
|
|
|
|
.pmd_entry = vmemmap_pmd_entry,
|
|
|
|
.pte_entry = vmemmap_pte_entry,
|
|
|
|
};
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
static int vmemmap_remap_range(unsigned long start, unsigned long end,
|
|
|
|
struct vmemmap_remap_walk *walk)
|
|
|
|
{
|
2023-11-27 16:46:43 +08:00
|
|
|
int ret;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2023-11-27 16:46:43 +08:00
|
|
|
VM_BUG_ON(!PAGE_ALIGNED(start | end));
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2023-12-05 11:08:53 +08:00
|
|
|
mmap_read_lock(&init_mm);
|
2023-11-27 16:46:43 +08:00
|
|
|
ret = walk_page_range_novma(&init_mm, start, end, &vmemmap_remap_ops,
|
|
|
|
NULL, walk);
|
2023-12-05 11:08:53 +08:00
|
|
|
mmap_read_unlock(&init_mm);
|
2023-11-27 16:46:43 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2023-10-19 10:31:09 +08:00
|
|
|
if (walk->remap_pte && !(walk->flags & VMEMMAP_REMAP_NO_TLB_FLUSH))
|
2023-10-19 10:31:08 +08:00
|
|
|
flush_tlb_kernel_range(start, end);
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free a vmemmap page. A vmemmap page can be allocated from the memblock
|
|
|
|
* allocator or buddy allocator. If the PG_reserved flag is set, it means
|
|
|
|
* that it allocated from the memblock allocator, just free it via the
|
|
|
|
* free_bootmem_page(). Otherwise, use __free_page().
|
|
|
|
*/
|
|
|
|
static inline void free_vmemmap_page(struct page *page)
|
|
|
|
{
|
2024-06-06 06:27:51 +08:00
|
|
|
if (PageReserved(page)) {
|
2022-06-28 17:22:31 +08:00
|
|
|
free_bootmem_page(page);
|
2024-06-06 06:27:51 +08:00
|
|
|
mod_node_page_state(page_pgdat(page), NR_MEMMAP_BOOT, -1);
|
|
|
|
} else {
|
2022-06-28 17:22:31 +08:00
|
|
|
__free_page(page);
|
2024-06-06 06:27:51 +08:00
|
|
|
mod_node_page_state(page_pgdat(page), NR_MEMMAP, -1);
|
|
|
|
}
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Free a list of the vmemmap pages */
|
|
|
|
static void free_vmemmap_page_list(struct list_head *list)
|
|
|
|
{
|
|
|
|
struct page *page, *next;
|
|
|
|
|
2022-10-27 11:36:41 +08:00
|
|
|
list_for_each_entry_safe(page, next, list, lru)
|
2022-06-28 17:22:31 +08:00
|
|
|
free_vmemmap_page(page);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void vmemmap_remap_pte(pte_t *pte, unsigned long addr,
|
|
|
|
struct vmemmap_remap_walk *walk)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Remap the tail pages as read-only to catch illegal write operation
|
|
|
|
* to the tail pages.
|
|
|
|
*/
|
|
|
|
pgprot_t pgprot = PAGE_KERNEL_RO;
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 23:15:45 +08:00
|
|
|
struct page *page = pte_page(ptep_get(pte));
|
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 23:39:22 +08:00
|
|
|
pte_t entry;
|
|
|
|
|
|
|
|
/* Remapping the head page requires r/w */
|
|
|
|
if (unlikely(addr == walk->reuse_addr)) {
|
|
|
|
pgprot = PAGE_KERNEL;
|
|
|
|
list_del(&walk->reuse_page->lru);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Makes sure that preceding stores to the page contents from
|
|
|
|
* vmemmap_remap_free() become visible before the set_pte_at()
|
|
|
|
* write.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
}
|
2022-06-28 17:22:31 +08:00
|
|
|
|
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 23:39:22 +08:00
|
|
|
entry = mk_pte(walk->reuse_page, pgprot);
|
2023-10-19 10:31:07 +08:00
|
|
|
list_add(&page->lru, walk->vmemmap_pages);
|
2022-06-28 17:22:31 +08:00
|
|
|
set_pte_at(&init_mm, addr, pte, entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* How many struct page structs need to be reset. When we reuse the head
|
|
|
|
* struct page, the special metadata (e.g. page->flags or page->mapping)
|
|
|
|
* cannot copy to the tail struct page structs. The invalid value will be
|
2023-04-05 22:28:40 +08:00
|
|
|
* checked in the free_tail_page_prepare(). In order to avoid the message
|
2022-06-28 17:22:31 +08:00
|
|
|
* of "corrupted mapping in tail page". We need to reset at least 3 (one
|
|
|
|
* head struct page struct and two tail struct page structs) struct page
|
|
|
|
* structs.
|
|
|
|
*/
|
|
|
|
#define NR_RESET_STRUCT_PAGE 3
|
|
|
|
|
|
|
|
static inline void reset_struct_pages(struct page *start)
|
|
|
|
{
|
|
|
|
struct page *from = start + NR_RESET_STRUCT_PAGE;
|
|
|
|
|
2022-08-19 11:55:32 +08:00
|
|
|
BUILD_BUG_ON(NR_RESET_STRUCT_PAGE * 2 > PAGE_SIZE / sizeof(struct page));
|
|
|
|
memcpy(start, from, sizeof(*from) * NR_RESET_STRUCT_PAGE);
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void vmemmap_restore_pte(pte_t *pte, unsigned long addr,
|
|
|
|
struct vmemmap_remap_walk *walk)
|
|
|
|
{
|
|
|
|
pgprot_t pgprot = PAGE_KERNEL;
|
|
|
|
struct page *page;
|
|
|
|
void *to;
|
|
|
|
|
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 23:15:45 +08:00
|
|
|
BUG_ON(pte_page(ptep_get(pte)) != walk->reuse_page);
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
page = list_first_entry(walk->vmemmap_pages, struct page, lru);
|
|
|
|
list_del(&page->lru);
|
|
|
|
to = page_to_virt(page);
|
|
|
|
copy_page(to, (void *)walk->reuse_addr);
|
|
|
|
reset_struct_pages(to);
|
|
|
|
|
2022-08-16 21:05:51 +08:00
|
|
|
/*
|
|
|
|
* Makes sure that preceding stores to the page contents become visible
|
|
|
|
* before the set_pte_at() write.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
2022-06-28 17:22:31 +08:00
|
|
|
set_pte_at(&init_mm, addr, pte, mk_pte(page, pgprot));
|
|
|
|
}
|
|
|
|
|
2023-10-19 10:31:08 +08:00
|
|
|
/**
|
|
|
|
* vmemmap_remap_split - split the vmemmap virtual address range [@start, @end)
|
|
|
|
* backing PMDs of the directmap into PTEs
|
|
|
|
* @start: start address of the vmemmap virtual address range that we want
|
|
|
|
* to remap.
|
|
|
|
* @end: end address of the vmemmap virtual address range that we want to
|
|
|
|
* remap.
|
|
|
|
* @reuse: reuse address.
|
|
|
|
*
|
|
|
|
* Return: %0 on success, negative error code otherwise.
|
|
|
|
*/
|
|
|
|
static int vmemmap_remap_split(unsigned long start, unsigned long end,
|
2023-11-27 16:46:45 +08:00
|
|
|
unsigned long reuse)
|
2023-10-19 10:31:08 +08:00
|
|
|
{
|
|
|
|
struct vmemmap_remap_walk walk = {
|
|
|
|
.remap_pte = NULL,
|
|
|
|
.flags = VMEMMAP_SPLIT_NO_TLB_FLUSH,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* See the comment in the vmemmap_remap_free(). */
|
|
|
|
BUG_ON(start - reuse != PAGE_SIZE);
|
|
|
|
|
2023-12-05 11:08:53 +08:00
|
|
|
return vmemmap_remap_range(reuse, end, &walk);
|
2023-10-19 10:31:08 +08:00
|
|
|
}
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
/**
|
|
|
|
* vmemmap_remap_free - remap the vmemmap virtual address range [@start, @end)
|
|
|
|
* to the page which @reuse is mapped to, then free vmemmap
|
|
|
|
* which the range are mapped to.
|
|
|
|
* @start: start address of the vmemmap virtual address range that we want
|
|
|
|
* to remap.
|
|
|
|
* @end: end address of the vmemmap virtual address range that we want to
|
|
|
|
* remap.
|
|
|
|
* @reuse: reuse address.
|
2023-10-19 10:31:07 +08:00
|
|
|
* @vmemmap_pages: list to deposit vmemmap pages to be freed. It is callers
|
|
|
|
* responsibility to free pages.
|
2023-10-19 10:31:09 +08:00
|
|
|
* @flags: modifications to vmemmap_remap_walk flags
|
2022-06-28 17:22:31 +08:00
|
|
|
*
|
|
|
|
* Return: %0 on success, negative error code otherwise.
|
|
|
|
*/
|
|
|
|
static int vmemmap_remap_free(unsigned long start, unsigned long end,
|
2023-10-19 10:31:07 +08:00
|
|
|
unsigned long reuse,
|
2023-10-19 10:31:09 +08:00
|
|
|
struct list_head *vmemmap_pages,
|
|
|
|
unsigned long flags)
|
2022-06-28 17:22:31 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct vmemmap_remap_walk walk = {
|
|
|
|
.remap_pte = vmemmap_remap_pte,
|
|
|
|
.reuse_addr = reuse,
|
2023-10-19 10:31:07 +08:00
|
|
|
.vmemmap_pages = vmemmap_pages,
|
2023-10-19 10:31:09 +08:00
|
|
|
.flags = flags,
|
2022-06-28 17:22:31 +08:00
|
|
|
};
|
2023-09-13 18:53:58 +08:00
|
|
|
int nid = page_to_nid((struct page *)reuse);
|
2023-09-06 17:31:57 +08:00
|
|
|
gfp_t gfp_mask = GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN;
|
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 23:39:22 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate a new head vmemmap page to avoid breaking a contiguous
|
|
|
|
* block of struct page memory when freeing it back to page allocator
|
|
|
|
* in free_vmemmap_page_list(). This will allow the likely contiguous
|
|
|
|
* struct page backing memory to be kept contiguous and allowing for
|
|
|
|
* more allocations of hugepages. Fallback to the currently
|
|
|
|
* mapped head page in case should it fail to allocate.
|
|
|
|
*/
|
|
|
|
walk.reuse_page = alloc_pages_node(nid, gfp_mask, 0);
|
|
|
|
if (walk.reuse_page) {
|
|
|
|
copy_page(page_to_virt(walk.reuse_page),
|
|
|
|
(void *)walk.reuse_addr);
|
2023-10-19 10:31:07 +08:00
|
|
|
list_add(&walk.reuse_page->lru, vmemmap_pages);
|
2024-06-06 06:27:51 +08:00
|
|
|
mod_node_page_state(NODE_DATA(nid), NR_MEMMAP, 1);
|
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 23:39:22 +08:00
|
|
|
}
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In order to make remapping routine most efficient for the huge pages,
|
|
|
|
* the routine of vmemmap page table walking has the following rules
|
|
|
|
* (see more details from the vmemmap_pte_range()):
|
|
|
|
*
|
|
|
|
* - The range [@start, @end) and the range [@reuse, @reuse + PAGE_SIZE)
|
|
|
|
* should be continuous.
|
|
|
|
* - The @reuse address is part of the range [@reuse, @end) that we are
|
|
|
|
* walking which is passed to vmemmap_remap_range().
|
|
|
|
* - The @reuse address is the first in the complete range.
|
|
|
|
*
|
|
|
|
* So we need to make sure that @start and @reuse meet the above rules.
|
|
|
|
*/
|
|
|
|
BUG_ON(start - reuse != PAGE_SIZE);
|
|
|
|
|
|
|
|
ret = vmemmap_remap_range(reuse, end, &walk);
|
|
|
|
if (ret && walk.nr_walked) {
|
|
|
|
end = reuse + walk.nr_walked * PAGE_SIZE;
|
|
|
|
/*
|
|
|
|
* vmemmap_pages contains pages from the previous
|
|
|
|
* vmemmap_remap_range call which failed. These
|
|
|
|
* are pages which were removed from the vmemmap.
|
|
|
|
* They will be restored in the following call.
|
|
|
|
*/
|
|
|
|
walk = (struct vmemmap_remap_walk) {
|
|
|
|
.remap_pte = vmemmap_restore_pte,
|
|
|
|
.reuse_addr = reuse,
|
2023-10-19 10:31:07 +08:00
|
|
|
.vmemmap_pages = vmemmap_pages,
|
2023-10-19 10:31:08 +08:00
|
|
|
.flags = 0,
|
2022-06-28 17:22:31 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
vmemmap_remap_range(reuse, end, &walk);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int alloc_vmemmap_page_list(unsigned long start, unsigned long end,
|
2023-05-09 07:40:59 +08:00
|
|
|
struct list_head *list)
|
2022-06-28 17:22:31 +08:00
|
|
|
{
|
2023-09-05 20:45:03 +08:00
|
|
|
gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL;
|
2022-06-28 17:22:31 +08:00
|
|
|
unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
|
|
|
|
int nid = page_to_nid((struct page *)start);
|
|
|
|
struct page *page, *next;
|
2024-06-06 06:27:51 +08:00
|
|
|
int i;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2024-06-06 06:27:51 +08:00
|
|
|
for (i = 0; i < nr_pages; i++) {
|
2022-06-28 17:22:31 +08:00
|
|
|
page = alloc_pages_node(nid, gfp_mask, 0);
|
2024-08-09 05:34:34 +08:00
|
|
|
if (!page)
|
2022-06-28 17:22:31 +08:00
|
|
|
goto out;
|
2023-10-19 10:31:07 +08:00
|
|
|
list_add(&page->lru, list);
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
2024-06-06 06:27:51 +08:00
|
|
|
mod_node_page_state(NODE_DATA(nid), NR_MEMMAP, nr_pages);
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
return 0;
|
|
|
|
out:
|
|
|
|
list_for_each_entry_safe(page, next, list, lru)
|
2023-03-13 20:27:14 +08:00
|
|
|
__free_page(page);
|
2022-06-28 17:22:31 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* vmemmap_remap_alloc - remap the vmemmap virtual address range [@start, end)
|
|
|
|
* to the page which is from the @vmemmap_pages
|
|
|
|
* respectively.
|
|
|
|
* @start: start address of the vmemmap virtual address range that we want
|
|
|
|
* to remap.
|
|
|
|
* @end: end address of the vmemmap virtual address range that we want to
|
|
|
|
* remap.
|
|
|
|
* @reuse: reuse address.
|
2023-10-19 10:31:10 +08:00
|
|
|
* @flags: modifications to vmemmap_remap_walk flags
|
2022-06-28 17:22:31 +08:00
|
|
|
*
|
|
|
|
* Return: %0 on success, negative error code otherwise.
|
|
|
|
*/
|
|
|
|
static int vmemmap_remap_alloc(unsigned long start, unsigned long end,
|
2023-10-19 10:31:10 +08:00
|
|
|
unsigned long reuse, unsigned long flags)
|
2022-06-28 17:22:31 +08:00
|
|
|
{
|
|
|
|
LIST_HEAD(vmemmap_pages);
|
|
|
|
struct vmemmap_remap_walk walk = {
|
|
|
|
.remap_pte = vmemmap_restore_pte,
|
|
|
|
.reuse_addr = reuse,
|
|
|
|
.vmemmap_pages = &vmemmap_pages,
|
2023-10-19 10:31:10 +08:00
|
|
|
.flags = flags,
|
2022-06-28 17:22:31 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* See the comment in the vmemmap_remap_free(). */
|
|
|
|
BUG_ON(start - reuse != PAGE_SIZE);
|
|
|
|
|
2023-05-09 07:40:59 +08:00
|
|
|
if (alloc_vmemmap_page_list(start, end, &vmemmap_pages))
|
2022-06-28 17:22:31 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2023-12-05 11:08:53 +08:00
|
|
|
return vmemmap_remap_range(reuse, end, &walk);
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
|
|
|
|
2022-06-28 17:22:29 +08:00
|
|
|
DEFINE_STATIC_KEY_FALSE(hugetlb_optimize_vmemmap_key);
|
2022-04-29 14:16:15 +08:00
|
|
|
EXPORT_SYMBOL(hugetlb_optimize_vmemmap_key);
|
2021-07-01 09:47:25 +08:00
|
|
|
|
2022-06-28 17:22:32 +08:00
|
|
|
static bool vmemmap_optimize_enabled = IS_ENABLED(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON);
|
|
|
|
core_param(hugetlb_free_vmemmap, vmemmap_optimize_enabled, bool, 0);
|
2021-07-01 09:47:13 +08:00
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
static int __hugetlb_vmemmap_restore_folio(const struct hstate *h,
|
|
|
|
struct folio *folio, unsigned long flags)
|
2021-07-01 09:47:21 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2023-11-27 16:46:45 +08:00
|
|
|
unsigned long vmemmap_start = (unsigned long)&folio->page, vmemmap_end;
|
2022-06-28 17:22:33 +08:00
|
|
|
unsigned long vmemmap_reuse;
|
2021-07-01 09:47:21 +08:00
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
VM_WARN_ON_ONCE_FOLIO(!folio_test_hugetlb(folio), folio);
|
mm/hugetlb_vmemmap: fix race with speculative PFN walkers
While investigating HVO for THPs [1], it turns out that speculative PFN
walkers like compaction can race with vmemmap modifications, e.g.,
CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
------------------------------- ------------------------------
Allocates an LRU folio page1
Sees page1
Frees page1
Allocates a hugeTLB folio page2
(page1 being a tail of page2)
Updates vmemmap mapping page1
get_page_unless_zero(page1)
Even though page1->_refcount is zero after HVO, get_page_unless_zero() can
still try to modify this read-only field, resulting in a crash.
An independent report [2] confirmed this race.
There are two discussed approaches to fix this race:
1. Make RO vmemmap RW so that get_page_unless_zero() can fail without
triggering a PF.
2. Use RCU to make sure get_page_unless_zero() either sees zero
page->_refcount through the old vmemmap or non-zero page->_refcount
through the new one.
The second approach is preferred here because:
1. It can prevent illegal modifications to struct page[] that has been
HVO'ed;
2. It can be generalized, in a way similar to ZERO_PAGE(), to fix
similar races in other places, e.g., arch_remove_memory() on x86
[3], which frees vmemmap mapping offlined struct page[].
While adding synchronize_rcu(), the goal is to be surgical, rather than
optimized. Specifically, calls to synchronize_rcu() on the error handling
paths can be coalesced, but it is not done for the sake of Simplicity:
noticeably, this fix removes ~50% more lines than it adds.
According to the hugetlb_optimize_vmemmap section in
Documentation/admin-guide/sysctl/vm.rst, enabling HVO makes allocating or
freeing hugeTLB pages "~2x slower than before". Having synchronize_rcu()
on top makes those operations even worse, and this also affects the user
interface /proc/sys/vm/nr_overcommit_hugepages.
This is *very* hard to trigger:
1. Most hugeTLB use cases I know of are static, i.e., reserved at
boot time, because allocating at runtime is not reliable at all.
2. On top of that, someone has to be very unlucky to get tripped
over above, because the race window is so small -- I wasn't able to
trigger it with a stress testing that does nothing but that (with
THPs though).
[1] https://lore.kernel.org/20240229183436.4110845-4-yuzhao@google.com/
[2] https://lore.kernel.org/917FFC7F-0615-44DD-90EE-9F85F8EA9974@linux.dev/
[3] https://lore.kernel.org/be130a96-a27e-4240-ad78-776802f57cad@redhat.com/
Link: https://lkml.kernel.org/r/20240627222705.2974207-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28 06:27:05 +08:00
|
|
|
VM_WARN_ON_ONCE_FOLIO(folio_ref_count(folio), folio);
|
|
|
|
|
2023-10-11 22:45:57 +08:00
|
|
|
if (!folio_test_hugetlb_vmemmap_optimized(folio))
|
2021-07-01 09:47:21 +08:00
|
|
|
return 0;
|
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size(h);
|
|
|
|
vmemmap_reuse = vmemmap_start;
|
|
|
|
vmemmap_start += HUGETLB_VMEMMAP_RESERVE_SIZE;
|
2022-04-29 14:16:14 +08:00
|
|
|
|
2021-07-01 09:47:21 +08:00
|
|
|
/*
|
2022-06-28 17:22:33 +08:00
|
|
|
* The pages which the vmemmap virtual address range [@vmemmap_start,
|
2021-07-01 09:47:21 +08:00
|
|
|
* @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.
|
|
|
|
*/
|
2023-10-19 10:31:10 +08:00
|
|
|
ret = vmemmap_remap_alloc(vmemmap_start, vmemmap_end, vmemmap_reuse, flags);
|
2022-05-14 07:48:56 +08:00
|
|
|
if (!ret) {
|
2023-10-11 22:45:57 +08:00
|
|
|
folio_clear_hugetlb_vmemmap_optimized(folio);
|
2022-05-14 07:48:56 +08:00
|
|
|
static_branch_dec(&hugetlb_optimize_vmemmap_key);
|
|
|
|
}
|
2021-07-01 09:47:21 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2023-10-19 10:31:10 +08:00
|
|
|
/**
|
2023-10-11 22:45:57 +08:00
|
|
|
* hugetlb_vmemmap_restore_folio - restore previously optimized (by
|
|
|
|
* hugetlb_vmemmap_optimize_folio()) vmemmap pages which
|
2023-10-19 10:31:10 +08:00
|
|
|
* will be reallocated and remapped.
|
|
|
|
* @h: struct hstate.
|
2023-10-11 22:45:57 +08:00
|
|
|
* @folio: the folio whose vmemmap pages will be restored.
|
2023-10-19 10:31:10 +08:00
|
|
|
*
|
2023-10-11 22:45:57 +08:00
|
|
|
* Return: %0 if @folio's vmemmap pages have been reallocated and remapped,
|
2023-10-19 10:31:10 +08:00
|
|
|
* negative error code otherwise.
|
|
|
|
*/
|
2023-10-11 22:45:57 +08:00
|
|
|
int hugetlb_vmemmap_restore_folio(const struct hstate *h, struct folio *folio)
|
2023-10-19 10:31:10 +08:00
|
|
|
{
|
mm/hugetlb_vmemmap: fix race with speculative PFN walkers
While investigating HVO for THPs [1], it turns out that speculative PFN
walkers like compaction can race with vmemmap modifications, e.g.,
CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
------------------------------- ------------------------------
Allocates an LRU folio page1
Sees page1
Frees page1
Allocates a hugeTLB folio page2
(page1 being a tail of page2)
Updates vmemmap mapping page1
get_page_unless_zero(page1)
Even though page1->_refcount is zero after HVO, get_page_unless_zero() can
still try to modify this read-only field, resulting in a crash.
An independent report [2] confirmed this race.
There are two discussed approaches to fix this race:
1. Make RO vmemmap RW so that get_page_unless_zero() can fail without
triggering a PF.
2. Use RCU to make sure get_page_unless_zero() either sees zero
page->_refcount through the old vmemmap or non-zero page->_refcount
through the new one.
The second approach is preferred here because:
1. It can prevent illegal modifications to struct page[] that has been
HVO'ed;
2. It can be generalized, in a way similar to ZERO_PAGE(), to fix
similar races in other places, e.g., arch_remove_memory() on x86
[3], which frees vmemmap mapping offlined struct page[].
While adding synchronize_rcu(), the goal is to be surgical, rather than
optimized. Specifically, calls to synchronize_rcu() on the error handling
paths can be coalesced, but it is not done for the sake of Simplicity:
noticeably, this fix removes ~50% more lines than it adds.
According to the hugetlb_optimize_vmemmap section in
Documentation/admin-guide/sysctl/vm.rst, enabling HVO makes allocating or
freeing hugeTLB pages "~2x slower than before". Having synchronize_rcu()
on top makes those operations even worse, and this also affects the user
interface /proc/sys/vm/nr_overcommit_hugepages.
This is *very* hard to trigger:
1. Most hugeTLB use cases I know of are static, i.e., reserved at
boot time, because allocating at runtime is not reliable at all.
2. On top of that, someone has to be very unlucky to get tripped
over above, because the race window is so small -- I wasn't able to
trigger it with a stress testing that does nothing but that (with
THPs though).
[1] https://lore.kernel.org/20240229183436.4110845-4-yuzhao@google.com/
[2] https://lore.kernel.org/917FFC7F-0615-44DD-90EE-9F85F8EA9974@linux.dev/
[3] https://lore.kernel.org/be130a96-a27e-4240-ad78-776802f57cad@redhat.com/
Link: https://lkml.kernel.org/r/20240627222705.2974207-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28 06:27:05 +08:00
|
|
|
/* avoid writes from page_ref_add_unless() while unfolding vmemmap */
|
|
|
|
synchronize_rcu();
|
|
|
|
|
2023-10-11 22:45:57 +08:00
|
|
|
return __hugetlb_vmemmap_restore_folio(h, folio, 0);
|
2023-10-19 10:31:10 +08:00
|
|
|
}
|
|
|
|
|
2023-10-19 10:31:06 +08:00
|
|
|
/**
|
|
|
|
* hugetlb_vmemmap_restore_folios - restore vmemmap for every folio on the list.
|
|
|
|
* @h: hstate.
|
|
|
|
* @folio_list: list of folios.
|
|
|
|
* @non_hvo_folios: Output list of folios for which vmemmap exists.
|
|
|
|
*
|
|
|
|
* Return: number of folios for which vmemmap was restored, or an error code
|
|
|
|
* if an error was encountered restoring vmemmap for a folio.
|
|
|
|
* Folios that have vmemmap are moved to the non_hvo_folios
|
|
|
|
* list. Processing of entries stops when the first error is
|
|
|
|
* encountered. The folio that experienced the error and all
|
|
|
|
* non-processed folios will remain on folio_list.
|
|
|
|
*/
|
|
|
|
long hugetlb_vmemmap_restore_folios(const struct hstate *h,
|
|
|
|
struct list_head *folio_list,
|
|
|
|
struct list_head *non_hvo_folios)
|
|
|
|
{
|
|
|
|
struct folio *folio, *t_folio;
|
|
|
|
long restored = 0;
|
|
|
|
long ret = 0;
|
|
|
|
|
mm/hugetlb_vmemmap: fix race with speculative PFN walkers
While investigating HVO for THPs [1], it turns out that speculative PFN
walkers like compaction can race with vmemmap modifications, e.g.,
CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
------------------------------- ------------------------------
Allocates an LRU folio page1
Sees page1
Frees page1
Allocates a hugeTLB folio page2
(page1 being a tail of page2)
Updates vmemmap mapping page1
get_page_unless_zero(page1)
Even though page1->_refcount is zero after HVO, get_page_unless_zero() can
still try to modify this read-only field, resulting in a crash.
An independent report [2] confirmed this race.
There are two discussed approaches to fix this race:
1. Make RO vmemmap RW so that get_page_unless_zero() can fail without
triggering a PF.
2. Use RCU to make sure get_page_unless_zero() either sees zero
page->_refcount through the old vmemmap or non-zero page->_refcount
through the new one.
The second approach is preferred here because:
1. It can prevent illegal modifications to struct page[] that has been
HVO'ed;
2. It can be generalized, in a way similar to ZERO_PAGE(), to fix
similar races in other places, e.g., arch_remove_memory() on x86
[3], which frees vmemmap mapping offlined struct page[].
While adding synchronize_rcu(), the goal is to be surgical, rather than
optimized. Specifically, calls to synchronize_rcu() on the error handling
paths can be coalesced, but it is not done for the sake of Simplicity:
noticeably, this fix removes ~50% more lines than it adds.
According to the hugetlb_optimize_vmemmap section in
Documentation/admin-guide/sysctl/vm.rst, enabling HVO makes allocating or
freeing hugeTLB pages "~2x slower than before". Having synchronize_rcu()
on top makes those operations even worse, and this also affects the user
interface /proc/sys/vm/nr_overcommit_hugepages.
This is *very* hard to trigger:
1. Most hugeTLB use cases I know of are static, i.e., reserved at
boot time, because allocating at runtime is not reliable at all.
2. On top of that, someone has to be very unlucky to get tripped
over above, because the race window is so small -- I wasn't able to
trigger it with a stress testing that does nothing but that (with
THPs though).
[1] https://lore.kernel.org/20240229183436.4110845-4-yuzhao@google.com/
[2] https://lore.kernel.org/917FFC7F-0615-44DD-90EE-9F85F8EA9974@linux.dev/
[3] https://lore.kernel.org/be130a96-a27e-4240-ad78-776802f57cad@redhat.com/
Link: https://lkml.kernel.org/r/20240627222705.2974207-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28 06:27:05 +08:00
|
|
|
/* avoid writes from page_ref_add_unless() while unfolding vmemmap */
|
|
|
|
synchronize_rcu();
|
|
|
|
|
2023-10-19 10:31:06 +08:00
|
|
|
list_for_each_entry_safe(folio, t_folio, folio_list, lru) {
|
|
|
|
if (folio_test_hugetlb_vmemmap_optimized(folio)) {
|
2023-10-11 22:45:57 +08:00
|
|
|
ret = __hugetlb_vmemmap_restore_folio(h, folio,
|
2023-11-27 16:46:45 +08:00
|
|
|
VMEMMAP_REMAP_NO_TLB_FLUSH);
|
2023-10-19 10:31:06 +08:00
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
restored++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add non-optimized folios to output list */
|
|
|
|
list_move(&folio->lru, non_hvo_folios);
|
|
|
|
}
|
|
|
|
|
2023-10-19 10:31:10 +08:00
|
|
|
if (restored)
|
|
|
|
flush_tlb_all();
|
2023-10-19 10:31:06 +08:00
|
|
|
if (!ret)
|
|
|
|
ret = restored;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
/* Return true iff a HugeTLB whose vmemmap should and can be optimized. */
|
2023-11-27 16:46:45 +08:00
|
|
|
static bool vmemmap_should_optimize_folio(const struct hstate *h, struct folio *folio)
|
2022-06-17 21:56:50 +08:00
|
|
|
{
|
2023-11-27 16:46:45 +08:00
|
|
|
if (folio_test_hugetlb_vmemmap_optimized(folio))
|
2023-10-19 10:31:05 +08:00
|
|
|
return false;
|
|
|
|
|
2022-06-28 17:22:29 +08:00
|
|
|
if (!READ_ONCE(vmemmap_optimize_enabled))
|
2022-06-28 17:22:33 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!hugetlb_vmemmap_optimizable(h))
|
|
|
|
return false;
|
2022-06-17 21:56:50 +08:00
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
return true;
|
2022-06-17 21:56:50 +08:00
|
|
|
}
|
|
|
|
|
2023-10-11 22:45:57 +08:00
|
|
|
static int __hugetlb_vmemmap_optimize_folio(const struct hstate *h,
|
2023-11-27 16:46:45 +08:00
|
|
|
struct folio *folio,
|
|
|
|
struct list_head *vmemmap_pages,
|
|
|
|
unsigned long flags)
|
2021-07-01 09:47:13 +08:00
|
|
|
{
|
2023-10-19 10:31:07 +08:00
|
|
|
int ret = 0;
|
2023-11-27 16:46:45 +08:00
|
|
|
unsigned long vmemmap_start = (unsigned long)&folio->page, vmemmap_end;
|
2022-06-28 17:22:33 +08:00
|
|
|
unsigned long vmemmap_reuse;
|
2021-07-01 09:47:13 +08:00
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
VM_WARN_ON_ONCE_FOLIO(!folio_test_hugetlb(folio), folio);
|
mm/hugetlb_vmemmap: fix race with speculative PFN walkers
While investigating HVO for THPs [1], it turns out that speculative PFN
walkers like compaction can race with vmemmap modifications, e.g.,
CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
------------------------------- ------------------------------
Allocates an LRU folio page1
Sees page1
Frees page1
Allocates a hugeTLB folio page2
(page1 being a tail of page2)
Updates vmemmap mapping page1
get_page_unless_zero(page1)
Even though page1->_refcount is zero after HVO, get_page_unless_zero() can
still try to modify this read-only field, resulting in a crash.
An independent report [2] confirmed this race.
There are two discussed approaches to fix this race:
1. Make RO vmemmap RW so that get_page_unless_zero() can fail without
triggering a PF.
2. Use RCU to make sure get_page_unless_zero() either sees zero
page->_refcount through the old vmemmap or non-zero page->_refcount
through the new one.
The second approach is preferred here because:
1. It can prevent illegal modifications to struct page[] that has been
HVO'ed;
2. It can be generalized, in a way similar to ZERO_PAGE(), to fix
similar races in other places, e.g., arch_remove_memory() on x86
[3], which frees vmemmap mapping offlined struct page[].
While adding synchronize_rcu(), the goal is to be surgical, rather than
optimized. Specifically, calls to synchronize_rcu() on the error handling
paths can be coalesced, but it is not done for the sake of Simplicity:
noticeably, this fix removes ~50% more lines than it adds.
According to the hugetlb_optimize_vmemmap section in
Documentation/admin-guide/sysctl/vm.rst, enabling HVO makes allocating or
freeing hugeTLB pages "~2x slower than before". Having synchronize_rcu()
on top makes those operations even worse, and this also affects the user
interface /proc/sys/vm/nr_overcommit_hugepages.
This is *very* hard to trigger:
1. Most hugeTLB use cases I know of are static, i.e., reserved at
boot time, because allocating at runtime is not reliable at all.
2. On top of that, someone has to be very unlucky to get tripped
over above, because the race window is so small -- I wasn't able to
trigger it with a stress testing that does nothing but that (with
THPs though).
[1] https://lore.kernel.org/20240229183436.4110845-4-yuzhao@google.com/
[2] https://lore.kernel.org/917FFC7F-0615-44DD-90EE-9F85F8EA9974@linux.dev/
[3] https://lore.kernel.org/be130a96-a27e-4240-ad78-776802f57cad@redhat.com/
Link: https://lkml.kernel.org/r/20240627222705.2974207-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28 06:27:05 +08:00
|
|
|
VM_WARN_ON_ONCE_FOLIO(folio_ref_count(folio), folio);
|
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
if (!vmemmap_should_optimize_folio(h, folio))
|
2023-10-19 10:31:07 +08:00
|
|
|
return ret;
|
2021-07-01 09:47:13 +08:00
|
|
|
|
2022-05-14 07:48:56 +08:00
|
|
|
static_branch_inc(&hugetlb_optimize_vmemmap_key);
|
2023-10-19 10:31:09 +08:00
|
|
|
/*
|
|
|
|
* Very Subtle
|
|
|
|
* If VMEMMAP_REMAP_NO_TLB_FLUSH is set, TLB flushing is not performed
|
|
|
|
* immediately after remapping. As a result, subsequent accesses
|
|
|
|
* and modifications to struct pages associated with the hugetlb
|
|
|
|
* page could be to the OLD struct pages. Set the vmemmap optimized
|
|
|
|
* flag here so that it is copied to the new head page. This keeps
|
|
|
|
* the old and new struct pages in sync.
|
|
|
|
* If there is an error during optimization, we will immediately FLUSH
|
|
|
|
* the TLB and clear the flag below.
|
|
|
|
*/
|
2023-10-11 22:45:57 +08:00
|
|
|
folio_set_hugetlb_vmemmap_optimized(folio);
|
2022-05-14 07:48:56 +08:00
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size(h);
|
|
|
|
vmemmap_reuse = vmemmap_start;
|
|
|
|
vmemmap_start += HUGETLB_VMEMMAP_RESERVE_SIZE;
|
2021-07-01 09:47:13 +08:00
|
|
|
|
|
|
|
/*
|
2022-06-28 17:22:33 +08:00
|
|
|
* Remap the vmemmap virtual address range [@vmemmap_start, @vmemmap_end)
|
2023-10-19 10:31:07 +08:00
|
|
|
* to the page which @vmemmap_reuse is mapped to. Add pages previously
|
|
|
|
* mapping the range to vmemmap_pages list so that they can be freed by
|
|
|
|
* the caller.
|
2021-07-01 09:47:13 +08:00
|
|
|
*/
|
2023-10-19 10:31:09 +08:00
|
|
|
ret = vmemmap_remap_free(vmemmap_start, vmemmap_end, vmemmap_reuse,
|
2023-11-27 16:46:45 +08:00
|
|
|
vmemmap_pages, flags);
|
2023-10-19 10:31:09 +08:00
|
|
|
if (ret) {
|
2022-05-14 07:48:56 +08:00
|
|
|
static_branch_dec(&hugetlb_optimize_vmemmap_key);
|
2023-10-11 22:45:57 +08:00
|
|
|
folio_clear_hugetlb_vmemmap_optimized(folio);
|
2023-10-19 10:31:09 +08:00
|
|
|
}
|
2023-10-19 10:31:07 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2023-10-11 22:45:57 +08:00
|
|
|
* hugetlb_vmemmap_optimize_folio - optimize @folio's vmemmap pages.
|
2023-10-19 10:31:07 +08:00
|
|
|
* @h: struct hstate.
|
2023-10-11 22:45:57 +08:00
|
|
|
* @folio: the folio whose vmemmap pages will be optimized.
|
2023-10-19 10:31:07 +08:00
|
|
|
*
|
2023-10-11 22:45:57 +08:00
|
|
|
* This function only tries to optimize @folio's vmemmap pages and does not
|
2023-10-19 10:31:07 +08:00
|
|
|
* guarantee that the optimization will succeed after it returns. The caller
|
2023-10-11 22:45:57 +08:00
|
|
|
* can use folio_test_hugetlb_vmemmap_optimized(@folio) to detect if @folio's
|
|
|
|
* vmemmap pages have been optimized.
|
2023-10-19 10:31:07 +08:00
|
|
|
*/
|
2023-10-11 22:45:57 +08:00
|
|
|
void hugetlb_vmemmap_optimize_folio(const struct hstate *h, struct folio *folio)
|
2023-10-19 10:31:07 +08:00
|
|
|
{
|
|
|
|
LIST_HEAD(vmemmap_pages);
|
|
|
|
|
mm/hugetlb_vmemmap: fix race with speculative PFN walkers
While investigating HVO for THPs [1], it turns out that speculative PFN
walkers like compaction can race with vmemmap modifications, e.g.,
CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
------------------------------- ------------------------------
Allocates an LRU folio page1
Sees page1
Frees page1
Allocates a hugeTLB folio page2
(page1 being a tail of page2)
Updates vmemmap mapping page1
get_page_unless_zero(page1)
Even though page1->_refcount is zero after HVO, get_page_unless_zero() can
still try to modify this read-only field, resulting in a crash.
An independent report [2] confirmed this race.
There are two discussed approaches to fix this race:
1. Make RO vmemmap RW so that get_page_unless_zero() can fail without
triggering a PF.
2. Use RCU to make sure get_page_unless_zero() either sees zero
page->_refcount through the old vmemmap or non-zero page->_refcount
through the new one.
The second approach is preferred here because:
1. It can prevent illegal modifications to struct page[] that has been
HVO'ed;
2. It can be generalized, in a way similar to ZERO_PAGE(), to fix
similar races in other places, e.g., arch_remove_memory() on x86
[3], which frees vmemmap mapping offlined struct page[].
While adding synchronize_rcu(), the goal is to be surgical, rather than
optimized. Specifically, calls to synchronize_rcu() on the error handling
paths can be coalesced, but it is not done for the sake of Simplicity:
noticeably, this fix removes ~50% more lines than it adds.
According to the hugetlb_optimize_vmemmap section in
Documentation/admin-guide/sysctl/vm.rst, enabling HVO makes allocating or
freeing hugeTLB pages "~2x slower than before". Having synchronize_rcu()
on top makes those operations even worse, and this also affects the user
interface /proc/sys/vm/nr_overcommit_hugepages.
This is *very* hard to trigger:
1. Most hugeTLB use cases I know of are static, i.e., reserved at
boot time, because allocating at runtime is not reliable at all.
2. On top of that, someone has to be very unlucky to get tripped
over above, because the race window is so small -- I wasn't able to
trigger it with a stress testing that does nothing but that (with
THPs though).
[1] https://lore.kernel.org/20240229183436.4110845-4-yuzhao@google.com/
[2] https://lore.kernel.org/917FFC7F-0615-44DD-90EE-9F85F8EA9974@linux.dev/
[3] https://lore.kernel.org/be130a96-a27e-4240-ad78-776802f57cad@redhat.com/
Link: https://lkml.kernel.org/r/20240627222705.2974207-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28 06:27:05 +08:00
|
|
|
/* avoid writes from page_ref_add_unless() while folding vmemmap */
|
|
|
|
synchronize_rcu();
|
|
|
|
|
2023-10-11 22:45:57 +08:00
|
|
|
__hugetlb_vmemmap_optimize_folio(h, folio, &vmemmap_pages, 0);
|
2023-10-19 10:31:07 +08:00
|
|
|
free_vmemmap_page_list(&vmemmap_pages);
|
2021-07-01 09:47:13 +08:00
|
|
|
}
|
2021-07-01 09:47:33 +08:00
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
static int hugetlb_vmemmap_split_folio(const struct hstate *h, struct folio *folio)
|
2023-10-19 10:31:08 +08:00
|
|
|
{
|
2023-11-27 16:46:45 +08:00
|
|
|
unsigned long vmemmap_start = (unsigned long)&folio->page, vmemmap_end;
|
2023-10-19 10:31:08 +08:00
|
|
|
unsigned long vmemmap_reuse;
|
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
if (!vmemmap_should_optimize_folio(h, folio))
|
2023-10-19 10:31:08 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size(h);
|
|
|
|
vmemmap_reuse = vmemmap_start;
|
|
|
|
vmemmap_start += HUGETLB_VMEMMAP_RESERVE_SIZE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Split PMDs on the vmemmap virtual address range [@vmemmap_start,
|
|
|
|
* @vmemmap_end]
|
|
|
|
*/
|
|
|
|
return vmemmap_remap_split(vmemmap_start, vmemmap_end, vmemmap_reuse);
|
|
|
|
}
|
|
|
|
|
2023-10-19 10:31:05 +08:00
|
|
|
void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_list)
|
|
|
|
{
|
|
|
|
struct folio *folio;
|
2023-10-19 10:31:07 +08:00
|
|
|
LIST_HEAD(vmemmap_pages);
|
|
|
|
|
2023-10-19 10:31:08 +08:00
|
|
|
list_for_each_entry(folio, folio_list, lru) {
|
2023-11-27 16:46:45 +08:00
|
|
|
int ret = hugetlb_vmemmap_split_folio(h, folio);
|
2023-10-19 10:31:08 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Spliting the PMD requires allocating a page, thus lets fail
|
|
|
|
* early once we encounter the first OOM. No point in retrying
|
|
|
|
* as it can be dynamically done on remap with the memory
|
|
|
|
* we get back from the vmemmap deduplication.
|
|
|
|
*/
|
|
|
|
if (ret == -ENOMEM)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
flush_tlb_all();
|
|
|
|
|
mm/hugetlb_vmemmap: fix race with speculative PFN walkers
While investigating HVO for THPs [1], it turns out that speculative PFN
walkers like compaction can race with vmemmap modifications, e.g.,
CPU 1 (vmemmap modifier) CPU 2 (speculative PFN walker)
------------------------------- ------------------------------
Allocates an LRU folio page1
Sees page1
Frees page1
Allocates a hugeTLB folio page2
(page1 being a tail of page2)
Updates vmemmap mapping page1
get_page_unless_zero(page1)
Even though page1->_refcount is zero after HVO, get_page_unless_zero() can
still try to modify this read-only field, resulting in a crash.
An independent report [2] confirmed this race.
There are two discussed approaches to fix this race:
1. Make RO vmemmap RW so that get_page_unless_zero() can fail without
triggering a PF.
2. Use RCU to make sure get_page_unless_zero() either sees zero
page->_refcount through the old vmemmap or non-zero page->_refcount
through the new one.
The second approach is preferred here because:
1. It can prevent illegal modifications to struct page[] that has been
HVO'ed;
2. It can be generalized, in a way similar to ZERO_PAGE(), to fix
similar races in other places, e.g., arch_remove_memory() on x86
[3], which frees vmemmap mapping offlined struct page[].
While adding synchronize_rcu(), the goal is to be surgical, rather than
optimized. Specifically, calls to synchronize_rcu() on the error handling
paths can be coalesced, but it is not done for the sake of Simplicity:
noticeably, this fix removes ~50% more lines than it adds.
According to the hugetlb_optimize_vmemmap section in
Documentation/admin-guide/sysctl/vm.rst, enabling HVO makes allocating or
freeing hugeTLB pages "~2x slower than before". Having synchronize_rcu()
on top makes those operations even worse, and this also affects the user
interface /proc/sys/vm/nr_overcommit_hugepages.
This is *very* hard to trigger:
1. Most hugeTLB use cases I know of are static, i.e., reserved at
boot time, because allocating at runtime is not reliable at all.
2. On top of that, someone has to be very unlucky to get tripped
over above, because the race window is so small -- I wasn't able to
trigger it with a stress testing that does nothing but that (with
THPs though).
[1] https://lore.kernel.org/20240229183436.4110845-4-yuzhao@google.com/
[2] https://lore.kernel.org/917FFC7F-0615-44DD-90EE-9F85F8EA9974@linux.dev/
[3] https://lore.kernel.org/be130a96-a27e-4240-ad78-776802f57cad@redhat.com/
Link: https://lkml.kernel.org/r/20240627222705.2974207-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@redhat.com>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-06-28 06:27:05 +08:00
|
|
|
/* avoid writes from page_ref_add_unless() while folding vmemmap */
|
|
|
|
synchronize_rcu();
|
|
|
|
|
2023-10-19 10:31:07 +08:00
|
|
|
list_for_each_entry(folio, folio_list, lru) {
|
2023-11-27 16:46:45 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = __hugetlb_vmemmap_optimize_folio(h, folio, &vmemmap_pages,
|
|
|
|
VMEMMAP_REMAP_NO_TLB_FLUSH);
|
2023-10-19 10:31:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Pages to be freed may have been accumulated. If we
|
|
|
|
* encounter an ENOMEM, free what we have and try again.
|
2023-10-19 10:31:09 +08:00
|
|
|
* This can occur in the case that both spliting fails
|
|
|
|
* halfway and head page allocation also failed. In this
|
2023-10-11 22:45:57 +08:00
|
|
|
* case __hugetlb_vmemmap_optimize_folio() would free memory
|
2023-10-19 10:31:09 +08:00
|
|
|
* allowing more vmemmap remaps to occur.
|
2023-10-19 10:31:07 +08:00
|
|
|
*/
|
|
|
|
if (ret == -ENOMEM && !list_empty(&vmemmap_pages)) {
|
2023-10-19 10:31:09 +08:00
|
|
|
flush_tlb_all();
|
2023-10-19 10:31:07 +08:00
|
|
|
free_vmemmap_page_list(&vmemmap_pages);
|
|
|
|
INIT_LIST_HEAD(&vmemmap_pages);
|
2023-11-27 16:46:45 +08:00
|
|
|
__hugetlb_vmemmap_optimize_folio(h, folio, &vmemmap_pages,
|
|
|
|
VMEMMAP_REMAP_NO_TLB_FLUSH);
|
2023-10-19 10:31:07 +08:00
|
|
|
}
|
|
|
|
}
|
2023-10-19 10:31:05 +08:00
|
|
|
|
2023-10-19 10:31:09 +08:00
|
|
|
flush_tlb_all();
|
2023-10-19 10:31:07 +08:00
|
|
|
free_vmemmap_page_list(&vmemmap_pages);
|
2023-10-19 10:31:05 +08:00
|
|
|
}
|
|
|
|
|
2022-05-14 07:48:56 +08:00
|
|
|
static struct ctl_table hugetlb_vmemmap_sysctls[] = {
|
|
|
|
{
|
|
|
|
.procname = "hugetlb_optimize_vmemmap",
|
2022-06-28 17:22:29 +08:00
|
|
|
.data = &vmemmap_optimize_enabled,
|
2023-02-10 22:58:23 +08:00
|
|
|
.maxlen = sizeof(vmemmap_optimize_enabled),
|
2022-05-14 07:48:56 +08:00
|
|
|
.mode = 0644,
|
2022-06-28 17:22:29 +08:00
|
|
|
.proc_handler = proc_dobool,
|
2022-05-14 07:48:56 +08:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
static int __init hugetlb_vmemmap_init(void)
|
2022-05-14 07:48:56 +08:00
|
|
|
{
|
2023-02-23 14:59:47 +08:00
|
|
|
const struct hstate *h;
|
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
/* HUGETLB_VMEMMAP_RESERVE_SIZE should cover all used struct pages */
|
2023-09-13 18:54:01 +08:00
|
|
|
BUILD_BUG_ON(__NR_USED_SUBPAGE > HUGETLB_VMEMMAP_RESERVE_PAGES);
|
2022-06-28 17:22:33 +08:00
|
|
|
|
2023-02-23 14:59:47 +08:00
|
|
|
for_each_hstate(h) {
|
|
|
|
if (hugetlb_vmemmap_optimizable(h)) {
|
|
|
|
register_sysctl_init("vm", hugetlb_vmemmap_sysctls);
|
|
|
|
break;
|
2022-06-28 17:22:33 +08:00
|
|
|
}
|
|
|
|
}
|
2022-05-14 07:48:56 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2022-06-28 17:22:33 +08:00
|
|
|
late_initcall(hugetlb_vmemmap_init);
|