2021-06-30 18:47:13 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/*
|
2022-06-28 17:22:30 +08:00
|
|
|
* HugeTLB Vmemmap Optimization (HVO)
|
2021-06-30 18:47:13 -07:00
|
|
|
*
|
2022-06-28 17:22:30 +08:00
|
|
|
* Copyright (c) 2020, ByteDance. All rights reserved.
|
2021-06-30 18:47:13 -07:00
|
|
|
*
|
|
|
|
|
* Author: Muchun Song <songmuchun@bytedance.com>
|
|
|
|
|
*
|
2022-06-27 09:00:26 +03:00
|
|
|
* See Documentation/mm/vmemmap_dedup.rst
|
2021-06-30 18:47:13 -07:00
|
|
|
*/
|
2021-06-30 18:47:25 -07:00
|
|
|
#define pr_fmt(fmt) "HugeTLB: " fmt
|
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
#include <linux/pgtable.h>
|
2022-11-02 19:09:17 +01:00
|
|
|
#include <linux/moduleparam.h>
|
2022-06-28 17:22:31 +08:00
|
|
|
#include <linux/bootmem_info.h>
|
2023-08-29 14:37:34 -07:00
|
|
|
#include <linux/mmdebug.h>
|
2023-11-27 16:46:43 +08:00
|
|
|
#include <linux/pagewalk.h>
|
2025-10-24 20:30:47 +09:00
|
|
|
#include <linux/pgalloc.h>
|
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
#include <asm/tlbflush.h>
|
2021-06-30 18:47:13 -07:00
|
|
|
#include "hugetlb_vmemmap.h"
|
2026-02-27 19:42:50 +00:00
|
|
|
#include "internal.h"
|
2021-06-30 18:47:13 -07:00
|
|
|
|
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.
|
2026-02-27 19:42:48 +00:00
|
|
|
* @vmemmap_head: the page to be installed as first in the vmemmap range
|
|
|
|
|
* @vmemmap_tail: the page to be installed as non-first in the vmemmap range
|
2022-06-28 17:22:31 +08:00
|
|
|
* @vmemmap_pages: the list head of the vmemmap pages that can be freed
|
|
|
|
|
* or is mapped from.
|
2023-10-18 19:31:08 -07: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);
|
2026-02-27 19:42:48 +00:00
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
unsigned long nr_walked;
|
2026-02-27 19:42:48 +00:00
|
|
|
struct page *vmemmap_head;
|
|
|
|
|
struct page *vmemmap_tail;
|
2022-06-28 17:22:31 +08:00
|
|
|
struct list_head *vmemmap_pages;
|
2023-10-18 19:31:08 -07:00
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
|
2023-10-18 19:31:08 -07:00
|
|
|
/* Skip the TLB flush when we split the PMD */
|
|
|
|
|
#define VMEMMAP_SPLIT_NO_TLB_FLUSH BIT(0)
|
2023-10-18 19:31:09 -07:00
|
|
|
/* Skip the TLB flush when we remap the PTE */
|
|
|
|
|
#define VMEMMAP_REMAP_NO_TLB_FLUSH BIT(1)
|
2023-10-18 19:31:08 -07: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;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2023-07-07 11:38:59 +08:00
|
|
|
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
|
2025-09-29 08:26:08 +08:00
|
|
|
* be treated as independent small pages (as they can be freed
|
2022-06-28 17:22:31 +08:00
|
|
|
* 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-18 19:31:08 -07: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;
|
|
|
|
|
|
|
|
|
|
/* Only splitting, not remapping the vmemmap pages. */
|
|
|
|
|
if (!vmemmap_walk->remap_pte)
|
|
|
|
|
walk->action = ACTION_CONTINUE;
|
|
|
|
|
|
|
|
|
|
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;
|
2023-11-27 16:46:43 +08:00
|
|
|
|
|
|
|
|
return vmemmap_split_pmd(pmd, head, addr & PMD_MASK, vmemmap_walk);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int vmemmap_pte_entry(pte_t *pte, unsigned long addr,
|
|
|
|
|
unsigned long next, struct mm_walk *walk)
|
|
|
|
|
{
|
|
|
|
|
struct vmemmap_remap_walk *vmemmap_walk = walk->private;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
vmemmap_walk->remap_pte(pte, addr, vmemmap_walk);
|
2023-11-27 16:46:43 +08:00
|
|
|
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);
|
mm/pagewalk: split walk_page_range_novma() into kernel/user parts
walk_page_range_novma() is rather confusing - it supports two modes, one
used often, the other used only for debugging.
The first mode is the common case of traversal of kernel page tables,
which is what nearly all callers use this for.
Secondly it provides an unusual debugging interface that allows for the
traversal of page tables in a userland range of memory even for that
memory which is not described by a VMA.
It is far from certain that such page tables should even exist, but
perhaps this is precisely why it is useful as a debugging mechanism.
As a result, this is utilised by ptdump only. Historically, things were
reversed - ptdump was the only user, and other parts of the kernel evolved
to use the kernel page table walking here.
Since we have some complicated and confusing locking rules for the novma
case, it makes sense to separate the two usages into their own functions.
Doing this also provide self-documentation as to the intent of the caller
- are they doing something rather unusual or are they simply doing a
standard kernel page table walk?
We therefore establish two separate functions - walk_page_range_debug()
for this single usage, and walk_kernel_page_table_range() for general
kernel page table walking.
The walk_page_range_debug() function is currently used to traverse both
userland and kernel mappings, so we maintain this and in the case of
kernel mappings being traversed, we have walk_page_range_debug() invoke
walk_kernel_page_table_range() internally.
We additionally make walk_page_range_debug() internal to mm.
Link: https://lkml.kernel.org/r/20250605135104.90720-1-lorenzo.stoakes@oracle.com
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Qi Zheng <zhengqi.arch@bytedance.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: David Hildenbrand <david@redhat.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexandre Ghiti <alex@ghiti.fr>
Cc: Barry Song <baohua@kernel.org>
Cc: Huacai Chen <chenhuacai@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Liam Howlett <liam.howlett@oracle.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Stafford Horne <shorne@gmail.com>
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: WANG Xuerui <kernel@xen0n.name>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-06-05 14:51:04 +01:00
|
|
|
ret = walk_kernel_page_table_range(start, end, &vmemmap_remap_ops,
|
2023-11-27 16:46:43 +08:00
|
|
|
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-18 19:31:09 -07:00
|
|
|
if (walk->remap_pte && !(walk->flags & VMEMMAP_REMAP_NO_TLB_FLUSH))
|
2023-10-18 19:31:08 -07: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-05 22:27:51 +00:00
|
|
|
if (PageReserved(page)) {
|
mm: don't account memmap per-node
Fix invalid access to pgdat during hot-remove operation:
ndctl users reported a GPF when trying to destroy a namespace:
$ ndctl destroy-namespace all -r all -f
Segmentation fault
dmesg:
Oops: general protection fault, probably for
non-canonical address 0xdffffc0000005650: 0000 [#1] PREEMPT SMP KASAN
PTI
KASAN: probably user-memory-access in range
[0x000000000002b280-0x000000000002b287]
CPU: 26 UID: 0 PID: 1868 Comm: ndctl Not tainted 6.11.0-rc1 #1
Hardware name: Dell Inc. PowerEdge R640/08HT8T, BIOS
2.20.1 09/13/2023
RIP: 0010:mod_node_page_state+0x2a/0x110
cxl-test users report a GPF when trying to unload the test module:
$ modrpobe -r cxl-test
dmesg
BUG: unable to handle page fault for address: 0000000000004200
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 UID: 0 PID: 1076 Comm: modprobe Tainted: G O N 6.11.0-rc1 #197
Tainted: [O]=OOT_MODULE, [N]=TEST
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/15
RIP: 0010:mod_node_page_state+0x6/0x90
Currently, when memory is hot-plugged or hot-removed the accounting is
done based on the assumption that memmap is allocated from the same node
as the hot-plugged/hot-removed memory, which is not always the case.
In addition, there are challenges with keeping the node id of the memory
that is being remove to the time when memmap accounting is actually
performed: since this is done after remove_pfn_range_from_zone(), and
also after remove_memory_block_devices(). Meaning that we cannot use
pgdat nor walking though memblocks to get the nid.
Given all of that, account the memmap overhead system wide instead.
For this we are going to be using global atomic counters, but given that
memmap size is rarely modified, and normally is only modified either
during early boot when there is only one CPU, or under a hotplug global
mutex lock, therefore there is no need for per-cpu optimizations.
Also, while we are here rename nr_memmap to nr_memmap_pages, and
nr_memmap_boot to nr_memmap_boot_pages to be self explanatory that the
units are in page count.
[pasha.tatashin@soleen.com: address a few nits from David Hildenbrand]
Link: https://lkml.kernel.org/r/20240809191020.1142142-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20240809191020.1142142-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20240808213437.682006-4-pasha.tatashin@soleen.com
Fixes: 15995a352474 ("mm: report per-page metadata information")
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Closes: https://lore.kernel.org/linux-cxl/CAHj4cs9Ax1=CoJkgBGP_+sNu6-6=6v=_L-ZBZY0bVLD3wUWZQg@mail.gmail.com
Reported-by: Alison Schofield <alison.schofield@intel.com>
Closes: https://lore.kernel.org/linux-mm/Zq0tPd2h6alFz8XF@aschofie-mobl2/#t
Tested-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
Cc: Fan Ni <fan.ni@samsung.com>
Cc: Joel Granados <j.granados@samsung.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Li Zhijian <lizhijian@fujitsu.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Sourav Panda <souravpanda@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-08-08 21:34:36 +00:00
|
|
|
memmap_boot_pages_add(-1);
|
2022-06-28 17:22:31 +08:00
|
|
|
free_bootmem_page(page);
|
2024-06-05 22:27:51 +00:00
|
|
|
} else {
|
mm: don't account memmap per-node
Fix invalid access to pgdat during hot-remove operation:
ndctl users reported a GPF when trying to destroy a namespace:
$ ndctl destroy-namespace all -r all -f
Segmentation fault
dmesg:
Oops: general protection fault, probably for
non-canonical address 0xdffffc0000005650: 0000 [#1] PREEMPT SMP KASAN
PTI
KASAN: probably user-memory-access in range
[0x000000000002b280-0x000000000002b287]
CPU: 26 UID: 0 PID: 1868 Comm: ndctl Not tainted 6.11.0-rc1 #1
Hardware name: Dell Inc. PowerEdge R640/08HT8T, BIOS
2.20.1 09/13/2023
RIP: 0010:mod_node_page_state+0x2a/0x110
cxl-test users report a GPF when trying to unload the test module:
$ modrpobe -r cxl-test
dmesg
BUG: unable to handle page fault for address: 0000000000004200
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 UID: 0 PID: 1076 Comm: modprobe Tainted: G O N 6.11.0-rc1 #197
Tainted: [O]=OOT_MODULE, [N]=TEST
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/15
RIP: 0010:mod_node_page_state+0x6/0x90
Currently, when memory is hot-plugged or hot-removed the accounting is
done based on the assumption that memmap is allocated from the same node
as the hot-plugged/hot-removed memory, which is not always the case.
In addition, there are challenges with keeping the node id of the memory
that is being remove to the time when memmap accounting is actually
performed: since this is done after remove_pfn_range_from_zone(), and
also after remove_memory_block_devices(). Meaning that we cannot use
pgdat nor walking though memblocks to get the nid.
Given all of that, account the memmap overhead system wide instead.
For this we are going to be using global atomic counters, but given that
memmap size is rarely modified, and normally is only modified either
during early boot when there is only one CPU, or under a hotplug global
mutex lock, therefore there is no need for per-cpu optimizations.
Also, while we are here rename nr_memmap to nr_memmap_pages, and
nr_memmap_boot to nr_memmap_boot_pages to be self explanatory that the
units are in page count.
[pasha.tatashin@soleen.com: address a few nits from David Hildenbrand]
Link: https://lkml.kernel.org/r/20240809191020.1142142-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20240809191020.1142142-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20240808213437.682006-4-pasha.tatashin@soleen.com
Fixes: 15995a352474 ("mm: report per-page metadata information")
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Closes: https://lore.kernel.org/linux-cxl/CAHj4cs9Ax1=CoJkgBGP_+sNu6-6=6v=_L-ZBZY0bVLD3wUWZQg@mail.gmail.com
Reported-by: Alison Schofield <alison.schofield@intel.com>
Closes: https://lore.kernel.org/linux-mm/Zq0tPd2h6alFz8XF@aschofie-mobl2/#t
Tested-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
Cc: Fan Ni <fan.ni@samsung.com>
Cc: Joel Granados <j.granados@samsung.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Li Zhijian <lizhijian@fujitsu.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Sourav Panda <souravpanda@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-08-08 21:34:36 +00:00
|
|
|
memmap_pages_add(-1);
|
2022-06-28 17:22:31 +08:00
|
|
|
__free_page(page);
|
2024-06-05 22:27:51 +00:00
|
|
|
}
|
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)
|
|
|
|
|
{
|
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 16:15:45 +01: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 15:39:22 +00:00
|
|
|
pte_t entry;
|
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 15:39:22 +00:00
|
|
|
/* Remapping the head page requires r/w */
|
2026-02-27 19:42:48 +00:00
|
|
|
if (unlikely(walk->nr_walked == 0 && walk->vmemmap_head)) {
|
2026-05-25 10:52:13 +08:00
|
|
|
VM_WARN_ON_ONCE(!PageHead((const struct page *)addr));
|
|
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
list_del(&walk->vmemmap_head->lru);
|
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 15:39:22 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Makes sure that preceding stores to the page contents from
|
|
|
|
|
* vmemmap_remap_free() become visible before the set_pte_at()
|
|
|
|
|
* write.
|
|
|
|
|
*/
|
|
|
|
|
smp_wmb();
|
2026-02-27 19:42:48 +00:00
|
|
|
|
|
|
|
|
entry = mk_pte(walk->vmemmap_head, PAGE_KERNEL);
|
|
|
|
|
} else {
|
2026-05-25 10:52:13 +08:00
|
|
|
VM_WARN_ON_ONCE(!PageTail((const struct page *)addr));
|
|
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
/*
|
|
|
|
|
* Remap the tail pages as read-only to catch illegal write
|
|
|
|
|
* operation to the tail pages.
|
|
|
|
|
*/
|
|
|
|
|
entry = mk_pte(walk->vmemmap_tail, PAGE_KERNEL_RO);
|
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 15:39:22 +00:00
|
|
|
}
|
|
|
|
|
|
2023-10-18 19:31:07 -07:00
|
|
|
list_add(&page->lru, walk->vmemmap_pages);
|
2022-06-28 17:22:31 +08:00
|
|
|
set_pte_at(&init_mm, addr, pte, entry);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void vmemmap_restore_pte(pte_t *pte, unsigned long addr,
|
|
|
|
|
struct vmemmap_remap_walk *walk)
|
|
|
|
|
{
|
2026-05-25 10:52:13 +08:00
|
|
|
struct page *src = pte_page(ptep_get(pte)), *dst;
|
2026-02-27 19:42:48 +00:00
|
|
|
|
|
|
|
|
/*
|
2026-05-25 10:52:13 +08:00
|
|
|
* When rolling back vmemmap_remap_free(), keep the copied head page
|
|
|
|
|
* mapping and restore only PTEs currently pointing at the shared tail
|
|
|
|
|
* page.
|
2026-02-27 19:42:48 +00:00
|
|
|
*/
|
2026-05-25 10:52:13 +08:00
|
|
|
if (walk->vmemmap_tail && walk->vmemmap_tail != src)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
VM_WARN_ON_ONCE(PageHead((const struct page *)addr));
|
|
|
|
|
|
|
|
|
|
dst = list_first_entry(walk->vmemmap_pages, struct page, lru);
|
|
|
|
|
list_del(&dst->lru);
|
|
|
|
|
copy_page(page_to_virt(dst), page_to_virt(src));
|
2022-06-28 17:22:31 +08:00
|
|
|
|
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();
|
2026-05-25 10:52:13 +08:00
|
|
|
set_pte_at(&init_mm, addr, pte, mk_pte(dst, PAGE_KERNEL));
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
|
|
|
|
|
2023-10-18 19:31:08 -07: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.
|
|
|
|
|
* Return: %0 on success, negative error code otherwise.
|
|
|
|
|
*/
|
2026-02-27 19:42:48 +00:00
|
|
|
static int vmemmap_remap_split(unsigned long start, unsigned long end)
|
2023-10-18 19:31:08 -07:00
|
|
|
{
|
|
|
|
|
struct vmemmap_remap_walk walk = {
|
|
|
|
|
.remap_pte = NULL,
|
|
|
|
|
.flags = VMEMMAP_SPLIT_NO_TLB_FLUSH,
|
|
|
|
|
};
|
|
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
return vmemmap_remap_range(start, end, &walk);
|
2023-10-18 19:31:08 -07:00
|
|
|
}
|
|
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
/**
|
|
|
|
|
* vmemmap_remap_free - remap the vmemmap virtual address range [@start, @end)
|
2026-02-27 19:42:48 +00:00
|
|
|
* to use @vmemmap_head/tail, then free vmemmap which
|
|
|
|
|
* the range are mapped to.
|
2022-06-28 17:22:31 +08:00
|
|
|
* @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.
|
2026-02-27 19:42:48 +00:00
|
|
|
* @vmemmap_head: the page to be installed as first in the vmemmap range
|
|
|
|
|
* @vmemmap_tail: the page to be installed as non-first in the vmemmap range
|
2023-10-18 19:31:07 -07:00
|
|
|
* @vmemmap_pages: list to deposit vmemmap pages to be freed. It is callers
|
|
|
|
|
* responsibility to free pages.
|
2023-10-18 19:31:09 -07: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,
|
2026-02-27 19:42:48 +00:00
|
|
|
struct page *vmemmap_head,
|
|
|
|
|
struct page *vmemmap_tail,
|
2023-10-18 19:31:09 -07: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,
|
2026-02-27 19:42:48 +00:00
|
|
|
.vmemmap_head = vmemmap_head,
|
|
|
|
|
.vmemmap_tail = vmemmap_tail,
|
2023-10-18 19:31:07 -07:00
|
|
|
.vmemmap_pages = vmemmap_pages,
|
2023-10-18 19:31:09 -07:00
|
|
|
.flags = flags,
|
2022-06-28 17:22:31 +08:00
|
|
|
};
|
2026-02-27 19:42:48 +00:00
|
|
|
|
|
|
|
|
ret = vmemmap_remap_range(start, end, &walk);
|
|
|
|
|
if (!ret || !walk.nr_walked)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
end = start + walk.nr_walked * PAGE_SIZE;
|
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 15:39:22 +00:00
|
|
|
|
|
|
|
|
/*
|
2026-02-27 19:42:48 +00:00
|
|
|
* 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.
|
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 15:39:22 +00:00
|
|
|
*/
|
2026-02-27 19:42:48 +00:00
|
|
|
walk = (struct vmemmap_remap_walk) {
|
|
|
|
|
.remap_pte = vmemmap_restore_pte,
|
2026-05-25 10:52:13 +08:00
|
|
|
.vmemmap_tail = vmemmap_tail,
|
2026-02-27 19:42:48 +00:00
|
|
|
.vmemmap_pages = vmemmap_pages,
|
|
|
|
|
.flags = 0,
|
|
|
|
|
};
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
vmemmap_remap_range(start, end, &walk);
|
2022-06-28 17:22:31 +08:00
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int alloc_vmemmap_page_list(unsigned long start, unsigned long end,
|
2023-05-08 23:40:59 +00: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-05 22:27:51 +00:00
|
|
|
int i;
|
2022-06-28 17:22:31 +08:00
|
|
|
|
2024-06-05 22:27:51 +00: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-08 21:34:34 +00:00
|
|
|
if (!page)
|
2022-06-28 17:22:31 +08:00
|
|
|
goto out;
|
2023-10-18 19:31:07 -07:00
|
|
|
list_add(&page->lru, list);
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
mm: don't account memmap per-node
Fix invalid access to pgdat during hot-remove operation:
ndctl users reported a GPF when trying to destroy a namespace:
$ ndctl destroy-namespace all -r all -f
Segmentation fault
dmesg:
Oops: general protection fault, probably for
non-canonical address 0xdffffc0000005650: 0000 [#1] PREEMPT SMP KASAN
PTI
KASAN: probably user-memory-access in range
[0x000000000002b280-0x000000000002b287]
CPU: 26 UID: 0 PID: 1868 Comm: ndctl Not tainted 6.11.0-rc1 #1
Hardware name: Dell Inc. PowerEdge R640/08HT8T, BIOS
2.20.1 09/13/2023
RIP: 0010:mod_node_page_state+0x2a/0x110
cxl-test users report a GPF when trying to unload the test module:
$ modrpobe -r cxl-test
dmesg
BUG: unable to handle page fault for address: 0000000000004200
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 UID: 0 PID: 1076 Comm: modprobe Tainted: G O N 6.11.0-rc1 #197
Tainted: [O]=OOT_MODULE, [N]=TEST
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/15
RIP: 0010:mod_node_page_state+0x6/0x90
Currently, when memory is hot-plugged or hot-removed the accounting is
done based on the assumption that memmap is allocated from the same node
as the hot-plugged/hot-removed memory, which is not always the case.
In addition, there are challenges with keeping the node id of the memory
that is being remove to the time when memmap accounting is actually
performed: since this is done after remove_pfn_range_from_zone(), and
also after remove_memory_block_devices(). Meaning that we cannot use
pgdat nor walking though memblocks to get the nid.
Given all of that, account the memmap overhead system wide instead.
For this we are going to be using global atomic counters, but given that
memmap size is rarely modified, and normally is only modified either
during early boot when there is only one CPU, or under a hotplug global
mutex lock, therefore there is no need for per-cpu optimizations.
Also, while we are here rename nr_memmap to nr_memmap_pages, and
nr_memmap_boot to nr_memmap_boot_pages to be self explanatory that the
units are in page count.
[pasha.tatashin@soleen.com: address a few nits from David Hildenbrand]
Link: https://lkml.kernel.org/r/20240809191020.1142142-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20240809191020.1142142-4-pasha.tatashin@soleen.com
Link: https://lkml.kernel.org/r/20240808213437.682006-4-pasha.tatashin@soleen.com
Fixes: 15995a352474 ("mm: report per-page metadata information")
Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Closes: https://lore.kernel.org/linux-cxl/CAHj4cs9Ax1=CoJkgBGP_+sNu6-6=6v=_L-ZBZY0bVLD3wUWZQg@mail.gmail.com
Reported-by: Alison Schofield <alison.schofield@intel.com>
Closes: https://lore.kernel.org/linux-mm/Zq0tPd2h6alFz8XF@aschofie-mobl2/#t
Tested-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Cc: Domenico Cerasuolo <cerasuolodomenico@gmail.com>
Cc: Fan Ni <fan.ni@samsung.com>
Cc: Joel Granados <j.granados@samsung.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Li Zhijian <lizhijian@fujitsu.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Nhat Pham <nphamcs@gmail.com>
Cc: Sourav Panda <souravpanda@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-08-08 21:34:36 +00:00
|
|
|
memmap_pages_add(nr_pages);
|
2024-06-05 22:27:51 +00:00
|
|
|
|
2022-06-28 17:22:31 +08:00
|
|
|
return 0;
|
|
|
|
|
out:
|
|
|
|
|
list_for_each_entry_safe(page, next, list, lru)
|
2023-03-13 12:27:14 +00: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.
|
2023-10-18 19:31:10 -07: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,
|
2026-02-27 19:42:48 +00:00
|
|
|
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,
|
|
|
|
|
.vmemmap_pages = &vmemmap_pages,
|
2023-10-18 19:31:10 -07:00
|
|
|
.flags = flags,
|
2022-06-28 17:22:31 +08:00
|
|
|
};
|
|
|
|
|
|
2023-05-08 23:40:59 +00:00
|
|
|
if (alloc_vmemmap_page_list(start, end, &vmemmap_pages))
|
2022-06-28 17:22:31 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
return vmemmap_remap_range(start, end, &walk);
|
2022-06-28 17:22:31 +08:00
|
|
|
}
|
|
|
|
|
|
2022-06-28 17:22:32 +08:00
|
|
|
static bool vmemmap_optimize_enabled = IS_ENABLED(CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON);
|
2025-02-28 18:29:08 +00:00
|
|
|
static int __init hugetlb_vmemmap_optimize_param(char *buf)
|
|
|
|
|
{
|
|
|
|
|
return kstrtobool(buf, &vmemmap_optimize_enabled);
|
|
|
|
|
}
|
|
|
|
|
early_param("hugetlb_free_vmemmap", hugetlb_vmemmap_optimize_param);
|
2021-06-30 18:47:13 -07: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-06-30 18:47:21 -07:00
|
|
|
{
|
|
|
|
|
int ret;
|
2026-02-27 19:42:48 +00:00
|
|
|
unsigned long vmemmap_start, vmemmap_end;
|
2021-06-30 18:47:21 -07: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-27 16:27:05 -06:00
|
|
|
VM_WARN_ON_ONCE_FOLIO(folio_ref_count(folio), folio);
|
|
|
|
|
|
2023-10-11 15:45:57 +01:00
|
|
|
if (!folio_test_hugetlb_vmemmap_optimized(folio))
|
2021-06-30 18:47:21 -07:00
|
|
|
return 0;
|
|
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
vmemmap_start = (unsigned long)&folio->page;
|
2022-06-28 17:22:33 +08:00
|
|
|
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size(h);
|
2026-02-27 19:42:48 +00:00
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
vmemmap_start += HUGETLB_VMEMMAP_RESERVE_SIZE;
|
2022-04-28 23:16:14 -07:00
|
|
|
|
2021-06-30 18:47:21 -07:00
|
|
|
/*
|
2022-06-28 17:22:33 +08:00
|
|
|
* The pages which the vmemmap virtual address range [@vmemmap_start,
|
2026-02-27 19:42:48 +00:00
|
|
|
* @vmemmap_end) are mapped to are freed to the buddy allocator.
|
2021-06-30 18:47:21 -07:00
|
|
|
* When a HugeTLB page is freed to the buddy allocator, previously
|
|
|
|
|
* discarded vmemmap pages must be allocated and remapping.
|
|
|
|
|
*/
|
2026-02-27 19:42:48 +00:00
|
|
|
ret = vmemmap_remap_alloc(vmemmap_start, vmemmap_end, flags);
|
2026-02-27 19:42:53 +00:00
|
|
|
if (!ret)
|
2023-10-11 15:45:57 +01:00
|
|
|
folio_clear_hugetlb_vmemmap_optimized(folio);
|
2021-06-30 18:47:21 -07:00
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-18 19:31:10 -07:00
|
|
|
/**
|
2023-10-11 15:45:57 +01:00
|
|
|
* hugetlb_vmemmap_restore_folio - restore previously optimized (by
|
|
|
|
|
* hugetlb_vmemmap_optimize_folio()) vmemmap pages which
|
2023-10-18 19:31:10 -07:00
|
|
|
* will be reallocated and remapped.
|
|
|
|
|
* @h: struct hstate.
|
2023-10-11 15:45:57 +01:00
|
|
|
* @folio: the folio whose vmemmap pages will be restored.
|
2023-10-18 19:31:10 -07:00
|
|
|
*
|
2023-10-11 15:45:57 +01:00
|
|
|
* Return: %0 if @folio's vmemmap pages have been reallocated and remapped,
|
2023-10-18 19:31:10 -07:00
|
|
|
* negative error code otherwise.
|
|
|
|
|
*/
|
2023-10-11 15:45:57 +01:00
|
|
|
int hugetlb_vmemmap_restore_folio(const struct hstate *h, struct folio *folio)
|
2023-10-18 19:31:10 -07:00
|
|
|
{
|
2026-02-27 19:42:52 +00:00
|
|
|
return __hugetlb_vmemmap_restore_folio(h, folio, 0);
|
2023-10-18 19:31:10 -07:00
|
|
|
}
|
|
|
|
|
|
2023-10-18 19:31:06 -07: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;
|
2026-02-27 19:42:52 +00:00
|
|
|
unsigned long flags = VMEMMAP_REMAP_NO_TLB_FLUSH;
|
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-27 16:27:05 -06:00
|
|
|
|
2023-10-18 19:31:06 -07:00
|
|
|
list_for_each_entry_safe(folio, t_folio, folio_list, lru) {
|
|
|
|
|
if (folio_test_hugetlb_vmemmap_optimized(folio)) {
|
2024-07-18 22:25:03 -06:00
|
|
|
ret = __hugetlb_vmemmap_restore_folio(h, folio, flags);
|
2023-10-18 19:31:06 -07:00
|
|
|
if (ret)
|
|
|
|
|
break;
|
|
|
|
|
restored++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add non-optimized folios to output list */
|
|
|
|
|
list_move(&folio->lru, non_hvo_folios);
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-18 19:31:10 -07:00
|
|
|
if (restored)
|
|
|
|
|
flush_tlb_all();
|
2023-10-18 19:31:06 -07: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-18 19:31:05 -07: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
|
|
|
}
|
|
|
|
|
|
2026-02-27 19:42:50 +00:00
|
|
|
static struct page *vmemmap_get_tail(unsigned int order, struct zone *zone)
|
|
|
|
|
{
|
|
|
|
|
const unsigned int idx = order - VMEMMAP_TAIL_MIN_ORDER;
|
|
|
|
|
struct page *tail, *p;
|
|
|
|
|
int node = zone_to_nid(zone);
|
|
|
|
|
|
|
|
|
|
tail = READ_ONCE(zone->vmemmap_tails[idx]);
|
|
|
|
|
if (likely(tail))
|
|
|
|
|
return tail;
|
|
|
|
|
|
|
|
|
|
tail = alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO, 0);
|
|
|
|
|
if (!tail)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
p = page_to_virt(tail);
|
|
|
|
|
for (int i = 0; i < PAGE_SIZE / sizeof(struct page); i++)
|
|
|
|
|
init_compound_tail(p + i, NULL, order, zone);
|
|
|
|
|
|
|
|
|
|
if (cmpxchg(&zone->vmemmap_tails[idx], NULL, tail)) {
|
|
|
|
|
__free_page(tail);
|
|
|
|
|
tail = READ_ONCE(zone->vmemmap_tails[idx]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return tail;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-11 15:45:57 +01: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)
|
2023-10-18 19:31:07 -07:00
|
|
|
{
|
2026-02-27 19:42:48 +00:00
|
|
|
unsigned long vmemmap_start, vmemmap_end;
|
|
|
|
|
struct page *vmemmap_head, *vmemmap_tail;
|
|
|
|
|
int nid, ret = 0;
|
2023-10-18 19:31:07 -07: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-27 16:27:05 -06: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-18 19:31:07 -07:00
|
|
|
return ret;
|
|
|
|
|
|
2026-02-27 19:42:50 +00:00
|
|
|
nid = folio_nid(folio);
|
|
|
|
|
vmemmap_tail = vmemmap_get_tail(h->order, folio_zone(folio));
|
|
|
|
|
if (!vmemmap_tail)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2023-10-18 19:31:09 -07: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 15:45:57 +01:00
|
|
|
folio_set_hugetlb_vmemmap_optimized(folio);
|
2023-10-18 19:31:07 -07:00
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
vmemmap_head = alloc_pages_node(nid, GFP_KERNEL, 0);
|
|
|
|
|
if (!vmemmap_head) {
|
|
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
copy_page(page_to_virt(vmemmap_head), folio);
|
|
|
|
|
list_add(&vmemmap_head->lru, vmemmap_pages);
|
|
|
|
|
memmap_pages_add(1);
|
|
|
|
|
|
|
|
|
|
vmemmap_start = (unsigned long)&folio->page;
|
2023-10-18 19:31:07 -07:00
|
|
|
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size(h);
|
|
|
|
|
|
|
|
|
|
/*
|
2026-02-27 19:42:48 +00:00
|
|
|
* Remap the vmemmap virtual address range [@vmemmap_start, @vmemmap_end).
|
|
|
|
|
* Add pages previously mapping the range to vmemmap_pages list so that
|
|
|
|
|
* they can be freed by the caller.
|
2023-10-18 19:31:07 -07:00
|
|
|
*/
|
2026-02-27 19:42:48 +00:00
|
|
|
ret = vmemmap_remap_free(vmemmap_start, vmemmap_end,
|
|
|
|
|
vmemmap_head, vmemmap_tail,
|
2023-11-27 16:46:45 +08:00
|
|
|
vmemmap_pages, flags);
|
2026-02-27 19:42:48 +00:00
|
|
|
out:
|
2026-02-27 19:42:53 +00:00
|
|
|
if (ret)
|
2023-10-11 15:45:57 +01:00
|
|
|
folio_clear_hugetlb_vmemmap_optimized(folio);
|
2023-10-18 19:31:07 -07:00
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
/**
|
2023-10-11 15:45:57 +01:00
|
|
|
* hugetlb_vmemmap_optimize_folio - optimize @folio's vmemmap pages.
|
2022-06-28 17:22:33 +08:00
|
|
|
* @h: struct hstate.
|
2023-10-11 15:45:57 +01:00
|
|
|
* @folio: the folio whose vmemmap pages will be optimized.
|
2022-06-28 17:22:33 +08:00
|
|
|
*
|
2023-10-11 15:45:57 +01:00
|
|
|
* This function only tries to optimize @folio's vmemmap pages and does not
|
2022-06-28 17:22:33 +08:00
|
|
|
* guarantee that the optimization will succeed after it returns. The caller
|
2023-10-11 15:45:57 +01:00
|
|
|
* can use folio_test_hugetlb_vmemmap_optimized(@folio) to detect if @folio's
|
|
|
|
|
* vmemmap pages have been optimized.
|
2022-06-28 17:22:33 +08:00
|
|
|
*/
|
2023-10-11 15:45:57 +01:00
|
|
|
void hugetlb_vmemmap_optimize_folio(const struct hstate *h, struct folio *folio)
|
2021-06-30 18:47:13 -07:00
|
|
|
{
|
2023-10-18 19:31:07 -07:00
|
|
|
LIST_HEAD(vmemmap_pages);
|
2021-06-30 18:47:13 -07:00
|
|
|
|
2026-02-27 19:42:52 +00:00
|
|
|
__hugetlb_vmemmap_optimize_folio(h, folio, &vmemmap_pages, 0);
|
2023-10-18 19:31:07 -07:00
|
|
|
free_vmemmap_page_list(&vmemmap_pages);
|
2021-06-30 18:47:13 -07:00
|
|
|
}
|
2021-06-30 18:47:33 -07:00
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
static int hugetlb_vmemmap_split_folio(const struct hstate *h, struct folio *folio)
|
2023-10-18 19:31:08 -07:00
|
|
|
{
|
2026-02-27 19:42:48 +00:00
|
|
|
unsigned long vmemmap_start, vmemmap_end;
|
2023-10-18 19:31:08 -07:00
|
|
|
|
2023-11-27 16:46:45 +08:00
|
|
|
if (!vmemmap_should_optimize_folio(h, folio))
|
2023-10-18 19:31:08 -07:00
|
|
|
return 0;
|
|
|
|
|
|
2026-02-27 19:42:48 +00:00
|
|
|
vmemmap_start = (unsigned long)&folio->page;
|
2023-10-18 19:31:08 -07:00
|
|
|
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size(h);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Split PMDs on the vmemmap virtual address range [@vmemmap_start,
|
|
|
|
|
* @vmemmap_end]
|
|
|
|
|
*/
|
2026-02-27 19:42:48 +00:00
|
|
|
return vmemmap_remap_split(vmemmap_start, vmemmap_end);
|
2023-10-18 19:31:08 -07:00
|
|
|
}
|
|
|
|
|
|
2025-02-28 18:29:18 +00:00
|
|
|
static void __hugetlb_vmemmap_optimize_folios(struct hstate *h,
|
|
|
|
|
struct list_head *folio_list,
|
|
|
|
|
bool boot)
|
2023-10-18 19:31:05 -07:00
|
|
|
{
|
|
|
|
|
struct folio *folio;
|
2025-02-28 18:29:18 +00:00
|
|
|
int nr_to_optimize;
|
2023-10-18 19:31:07 -07:00
|
|
|
LIST_HEAD(vmemmap_pages);
|
2026-02-27 19:42:52 +00:00
|
|
|
unsigned long flags = VMEMMAP_REMAP_NO_TLB_FLUSH;
|
2023-10-18 19:31:05 -07:00
|
|
|
|
2025-02-28 18:29:18 +00:00
|
|
|
nr_to_optimize = 0;
|
2023-10-18 19:31:08 -07:00
|
|
|
list_for_each_entry(folio, folio_list, lru) {
|
2025-02-28 18:29:18 +00:00
|
|
|
int ret;
|
|
|
|
|
unsigned long spfn, epfn;
|
|
|
|
|
|
|
|
|
|
if (boot && folio_test_hugetlb_vmemmap_optimized(folio)) {
|
|
|
|
|
/*
|
|
|
|
|
* Already optimized by pre-HVO, just map the
|
|
|
|
|
* mirrored tail page structs RO.
|
|
|
|
|
*/
|
|
|
|
|
spfn = (unsigned long)&folio->page;
|
|
|
|
|
epfn = spfn + pages_per_huge_page(h);
|
|
|
|
|
vmemmap_wrprotect_hvo(spfn, epfn, folio_nid(folio),
|
|
|
|
|
HUGETLB_VMEMMAP_RESERVE_SIZE);
|
|
|
|
|
register_page_bootmem_memmap(pfn_to_section_nr(spfn),
|
|
|
|
|
&folio->page,
|
|
|
|
|
HUGETLB_VMEMMAP_RESERVE_SIZE);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nr_to_optimize++;
|
|
|
|
|
|
|
|
|
|
ret = hugetlb_vmemmap_split_folio(h, folio);
|
2023-10-18 19:31:08 -07:00
|
|
|
|
|
|
|
|
/*
|
2025-09-29 08:26:08 +08:00
|
|
|
* Splitting the PMD requires allocating a page, thus let's fail
|
2023-10-18 19:31:08 -07:00
|
|
|
* 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;
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-28 18:29:18 +00:00
|
|
|
if (!nr_to_optimize)
|
|
|
|
|
/*
|
|
|
|
|
* All pre-HVO folios, nothing left to do. It's ok if
|
|
|
|
|
* there is a mix of pre-HVO and not yet HVO-ed folios
|
|
|
|
|
* here, as __hugetlb_vmemmap_optimize_folio() will
|
|
|
|
|
* skip any folios that already have the optimized flag
|
|
|
|
|
* set, see vmemmap_should_optimize_folio().
|
|
|
|
|
*/
|
|
|
|
|
goto out;
|
|
|
|
|
|
2023-10-18 19:31:08 -07:00
|
|
|
flush_tlb_all();
|
|
|
|
|
|
2023-10-18 19:31:07 -07:00
|
|
|
list_for_each_entry(folio, folio_list, lru) {
|
2023-11-27 16:46:45 +08:00
|
|
|
int ret;
|
|
|
|
|
|
2024-07-18 22:25:03 -06:00
|
|
|
ret = __hugetlb_vmemmap_optimize_folio(h, folio, &vmemmap_pages, flags);
|
2023-10-18 19:31:07 -07:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Pages to be freed may have been accumulated. If we
|
|
|
|
|
* encounter an ENOMEM, free what we have and try again.
|
2025-09-29 08:26:08 +08:00
|
|
|
* This can occur in the case that both splitting fails
|
2023-10-18 19:31:09 -07:00
|
|
|
* halfway and head page allocation also failed. In this
|
2023-10-11 15:45:57 +01:00
|
|
|
* case __hugetlb_vmemmap_optimize_folio() would free memory
|
2023-10-18 19:31:09 -07:00
|
|
|
* allowing more vmemmap remaps to occur.
|
2023-10-18 19:31:07 -07:00
|
|
|
*/
|
|
|
|
|
if (ret == -ENOMEM && !list_empty(&vmemmap_pages)) {
|
2023-10-18 19:31:09 -07:00
|
|
|
flush_tlb_all();
|
2023-10-18 19:31:07 -07:00
|
|
|
free_vmemmap_page_list(&vmemmap_pages);
|
|
|
|
|
INIT_LIST_HEAD(&vmemmap_pages);
|
2024-07-18 22:25:03 -06:00
|
|
|
__hugetlb_vmemmap_optimize_folio(h, folio, &vmemmap_pages, flags);
|
2023-10-18 19:31:07 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-02-28 18:29:18 +00:00
|
|
|
out:
|
2023-10-18 19:31:09 -07:00
|
|
|
flush_tlb_all();
|
2023-10-18 19:31:07 -07:00
|
|
|
free_vmemmap_page_list(&vmemmap_pages);
|
2023-10-18 19:31:05 -07:00
|
|
|
}
|
|
|
|
|
|
2025-02-28 18:29:18 +00:00
|
|
|
void hugetlb_vmemmap_optimize_folios(struct hstate *h, struct list_head *folio_list)
|
|
|
|
|
{
|
|
|
|
|
__hugetlb_vmemmap_optimize_folios(h, folio_list, false);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void hugetlb_vmemmap_optimize_bootmem_folios(struct hstate *h, struct list_head *folio_list)
|
|
|
|
|
{
|
|
|
|
|
__hugetlb_vmemmap_optimize_folios(h, folio_list, true);
|
|
|
|
|
}
|
|
|
|
|
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
#ifdef CONFIG_SPARSEMEM_VMEMMAP_PREINIT
|
|
|
|
|
|
|
|
|
|
/* Return true of a bootmem allocated HugeTLB page should be pre-HVO-ed */
|
|
|
|
|
static bool vmemmap_should_optimize_bootmem_page(struct huge_bootmem_page *m)
|
|
|
|
|
{
|
|
|
|
|
unsigned long section_size, psize, pmd_vmemmap_size;
|
|
|
|
|
phys_addr_t paddr;
|
|
|
|
|
|
|
|
|
|
if (!READ_ONCE(vmemmap_optimize_enabled))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (!hugetlb_vmemmap_optimizable(m->hstate))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
psize = huge_page_size(m->hstate);
|
|
|
|
|
paddr = virt_to_phys(m);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Pre-HVO only works if the bootmem huge page
|
|
|
|
|
* is aligned to the section size.
|
|
|
|
|
*/
|
|
|
|
|
section_size = (1UL << PA_SECTION_SHIFT);
|
|
|
|
|
if (!IS_ALIGNED(paddr, section_size) ||
|
|
|
|
|
!IS_ALIGNED(psize, section_size))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The pre-HVO code does not deal with splitting PMDS,
|
|
|
|
|
* so the bootmem page must be aligned to the number
|
|
|
|
|
* of base pages that can be mapped with one vmemmap PMD.
|
|
|
|
|
*/
|
|
|
|
|
pmd_vmemmap_size = (PMD_SIZE / (sizeof(struct page))) << PAGE_SHIFT;
|
|
|
|
|
if (!IS_ALIGNED(paddr, pmd_vmemmap_size) ||
|
|
|
|
|
!IS_ALIGNED(psize, pmd_vmemmap_size))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Initialize memmap section for a gigantic page, HVO-style.
|
|
|
|
|
*/
|
|
|
|
|
void __init hugetlb_vmemmap_init_early(int nid)
|
|
|
|
|
{
|
|
|
|
|
unsigned long psize, paddr, section_size;
|
|
|
|
|
unsigned long ns, i, pnum, pfn, nr_pages;
|
|
|
|
|
struct huge_bootmem_page *m = NULL;
|
|
|
|
|
void *map;
|
|
|
|
|
|
|
|
|
|
if (!READ_ONCE(vmemmap_optimize_enabled))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
section_size = (1UL << PA_SECTION_SHIFT);
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(m, &huge_boot_pages[nid], list) {
|
|
|
|
|
if (!vmemmap_should_optimize_bootmem_page(m))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
nr_pages = pages_per_huge_page(m->hstate);
|
|
|
|
|
psize = nr_pages << PAGE_SHIFT;
|
|
|
|
|
paddr = virt_to_phys(m);
|
|
|
|
|
pfn = PHYS_PFN(paddr);
|
|
|
|
|
map = pfn_to_page(pfn);
|
|
|
|
|
|
|
|
|
|
pnum = pfn_to_section_nr(pfn);
|
|
|
|
|
ns = psize / section_size;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ns; i++) {
|
|
|
|
|
sparse_init_early_section(nid, map, pnum,
|
|
|
|
|
SECTION_IS_VMEMMAP_PREINIT);
|
|
|
|
|
map += section_map_size();
|
|
|
|
|
pnum++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
m->flags |= HUGE_BOOTMEM_HVO;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2026-02-27 19:42:50 +00:00
|
|
|
static struct zone *pfn_to_zone(unsigned nid, unsigned long pfn)
|
|
|
|
|
{
|
|
|
|
|
struct zone *zone;
|
|
|
|
|
enum zone_type zone_type;
|
|
|
|
|
|
|
|
|
|
for (zone_type = 0; zone_type < MAX_NR_ZONES; zone_type++) {
|
|
|
|
|
zone = &NODE_DATA(nid)->node_zones[zone_type];
|
|
|
|
|
if (zone_spans_pfn(zone, pfn))
|
|
|
|
|
return zone;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
void __init hugetlb_vmemmap_init_late(int nid)
|
|
|
|
|
{
|
|
|
|
|
struct huge_bootmem_page *m, *tm;
|
|
|
|
|
unsigned long phys, nr_pages, start, end;
|
|
|
|
|
unsigned long pfn, nr_mmap;
|
2026-02-27 19:42:50 +00:00
|
|
|
struct zone *zone = NULL;
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
struct hstate *h;
|
|
|
|
|
void *map;
|
|
|
|
|
|
|
|
|
|
if (!READ_ONCE(vmemmap_optimize_enabled))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(m, tm, &huge_boot_pages[nid], list) {
|
|
|
|
|
if (!(m->flags & HUGE_BOOTMEM_HVO))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
phys = virt_to_phys(m);
|
|
|
|
|
h = m->hstate;
|
|
|
|
|
pfn = PHYS_PFN(phys);
|
|
|
|
|
nr_pages = pages_per_huge_page(h);
|
2026-02-27 19:42:47 +00:00
|
|
|
map = pfn_to_page(pfn);
|
|
|
|
|
start = (unsigned long)map;
|
|
|
|
|
end = start + nr_pages * sizeof(struct page);
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
|
|
|
|
|
if (!hugetlb_bootmem_page_zones_valid(nid, m)) {
|
|
|
|
|
/*
|
|
|
|
|
* Oops, the hugetlb page spans multiple zones.
|
2026-02-27 19:42:47 +00:00
|
|
|
* Remove it from the list, and populate it normally.
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
*/
|
|
|
|
|
list_del(&m->list);
|
|
|
|
|
|
2026-02-27 19:42:47 +00:00
|
|
|
vmemmap_populate(start, end, nid, NULL);
|
|
|
|
|
nr_mmap = end - start;
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
memmap_boot_pages_add(DIV_ROUND_UP(nr_mmap, PAGE_SIZE));
|
|
|
|
|
|
|
|
|
|
memblock_phys_free(phys, huge_page_size(h));
|
|
|
|
|
continue;
|
2026-02-27 19:42:47 +00:00
|
|
|
}
|
|
|
|
|
|
2026-02-27 19:42:50 +00:00
|
|
|
if (!zone || !zone_spans_pfn(zone, pfn))
|
|
|
|
|
zone = pfn_to_zone(nid, pfn);
|
|
|
|
|
if (WARN_ON_ONCE(!zone))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (vmemmap_populate_hvo(start, end, huge_page_order(h), zone,
|
2026-02-27 19:42:47 +00:00
|
|
|
HUGETLB_VMEMMAP_RESERVE_SIZE) < 0) {
|
|
|
|
|
/* Fallback if HVO population fails */
|
|
|
|
|
vmemmap_populate(start, end, nid, NULL);
|
|
|
|
|
nr_mmap = end - start;
|
|
|
|
|
} else {
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
m->flags |= HUGE_BOOTMEM_ZONES_VALID;
|
2026-02-27 19:42:47 +00:00
|
|
|
nr_mmap = HUGETLB_VMEMMAP_RESERVE_SIZE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
memmap_boot_pages_add(DIV_ROUND_UP(nr_mmap, PAGE_SIZE));
|
mm/hugetlb: do pre-HVO for bootmem allocated pages
For large systems, the overhead of vmemmap pages for hugetlb is
substantial. It's about 1.5% of memory, which is about 45G for a 3T
system. If you want to configure most of that system for hugetlb (e.g.
to use as backing memory for VMs), there is a chance of running out of
memory on boot, even though you know that the 45G will become available
later.
To avoid this scenario, and since it's a waste to first allocate and then
free that 45G during boot, do pre-HVO for hugetlb bootmem allocated pages
('gigantic' pages).
pre-HVO is done by adding functions that are called from
sparse_init_nid_early and sparse_init_nid_late. The first is called
before memmap allocation, so it takes care of allocating memmap HVO-style.
The second verifies that all bootmem pages look good, specifically it
checks that they do not intersect with multiple zones. This can only be
done from sparse_init_nid_late path, when zones have been initialized.
The hugetlb page size must be aligned to the section size, and aligned to
the size of memory described by the number of page structures contained in
one PMD (since pre-HVO is not prepared to split PMDs). This should be
true for most 'gigantic' pages, it is for 1G pages on x86, where both of
these alignment requirements are 128M.
This will only have an effect if hugetlb_bootmem_alloc was called early in
boot. If not, it won't do anything, and HVO for bootmem hugetlb pages
works as before.
Link: https://lkml.kernel.org/r/20250228182928.2645936-20-fvdl@google.com
Signed-off-by: Frank van der Linden <fvdl@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roman Gushchin (Cruise) <roman.gushchin@linux.dev>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Yu Zhao <yuzhao@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-28 18:29:20 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2025-01-28 13:48:37 +01:00
|
|
|
static const struct ctl_table hugetlb_vmemmap_sysctls[] = {
|
2022-05-13 16:48:56 -07:00
|
|
|
{
|
|
|
|
|
.procname = "hugetlb_optimize_vmemmap",
|
2022-06-28 17:22:29 +08:00
|
|
|
.data = &vmemmap_optimize_enabled,
|
2023-02-10 15:58:23 +01:00
|
|
|
.maxlen = sizeof(vmemmap_optimize_enabled),
|
2022-05-13 16:48:56 -07:00
|
|
|
.mode = 0644,
|
2022-06-28 17:22:29 +08:00
|
|
|
.proc_handler = proc_dobool,
|
2022-05-13 16:48:56 -07:00
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
static int __init hugetlb_vmemmap_init(void)
|
2022-05-13 16:48:56 -07:00
|
|
|
{
|
2023-02-23 14:59:47 +08:00
|
|
|
const struct hstate *h;
|
2026-02-27 19:42:50 +00:00
|
|
|
struct zone *zone;
|
2023-02-23 14:59:47 +08:00
|
|
|
|
2022-06-28 17:22:33 +08:00
|
|
|
/* HUGETLB_VMEMMAP_RESERVE_SIZE should cover all used struct pages */
|
2023-09-13 11:54:01 +01:00
|
|
|
BUILD_BUG_ON(__NR_USED_SUBPAGE > HUGETLB_VMEMMAP_RESERVE_PAGES);
|
2022-05-13 16:48:56 -07:00
|
|
|
|
2026-02-27 19:42:50 +00:00
|
|
|
for_each_zone(zone) {
|
|
|
|
|
for (int i = 0; i < NR_VMEMMAP_TAILS; i++) {
|
|
|
|
|
struct page *tail, *p;
|
|
|
|
|
unsigned int order;
|
|
|
|
|
|
|
|
|
|
tail = zone->vmemmap_tails[i];
|
|
|
|
|
if (!tail)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
order = i + VMEMMAP_TAIL_MIN_ORDER;
|
|
|
|
|
p = page_to_virt(tail);
|
|
|
|
|
for (int j = 0; j < PAGE_SIZE / sizeof(struct page); j++)
|
|
|
|
|
init_compound_tail(p + j, NULL, order, zone);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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-13 16:48:56 -07:00
|
|
|
return 0;
|
|
|
|
|
}
|
2022-06-28 17:22:33 +08:00
|
|
|
late_initcall(hugetlb_vmemmap_init);
|