mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-08-27 14:04:47 -04:00
Pull more liveupdate updates from Mike Rapoport:
"Make boot time huge page allocation work nicely with kexec handover.
Today allocation of gigantic pages in HugeTLB cannot work reliably
with kexec handover (KHO):
- HugeTLB allocates gigantic pages using memblock and autoscaling of
KHO scratch accounts for these allocations. When gigantic pages
occupy half of the memory of more, KHO fails to allocate its
scratch memory.
- After kexec handover, memblock allocations exclusively use KHO
scratch that is not supposed to contain preserved memory. This
essentially blocks preservation of HugeTLB with gigantic pages.
Extend early memory pools available for KHO kernel with areas that are
guaranteed not to contain preserved memory"
* tag 'liveupdate-v7.3-rc1-20260823' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux: (21 commits)
kho: exclude hugetlb memory from scratch size calculation
memblock: add memblock_reserved_hugetlb_size()
memblock: make HugeTLB bootmem allocation work with KHO
memblock: always include KHO headers
kho: extend scratch
mm/mm_init: don't rely on memblock to get KHO scratch migratetype
kho: initialize preserved memory map radix tree earlier
kho: initialize kho_scratch pointer earlier in boot
kho: expose kho_scratch_overlap() to kexec_handover.h
kho: add kho_radix_init_tree()
kho: allow destroying KHO radix tree
kho: allow early-boot usage of the KHO radix tree
kho: add data argument to radix walk callback
kho: add callback for table pages
kho: add a struct for radix callbacks
kho: move all memory retrieval logic to kho_mem_retrieve()
kho: store incoming radix tree in kho_in
kho: disallow wide keys in radix tree
kho: make radix max key width more obvious
kho: generalize radix tree APIs
...
==================
Memblock simulator
==================
Introduction
============
Memblock is a boot time memory allocator[1] that manages memory regions before
the actual memory management is initialized. Its APIs allow to register physical
memory regions, mark them as available or reserved, allocate a block of memory
within the requested range and/or in specific NUMA node, and many more.
Because it is used so early in the booting process, testing and debugging it is
difficult. This test suite, usually referred as memblock simulator, is
an attempt at testing the memblock mechanism. It runs one monolithic test that
consist of a series of checks that exercise both the basic operations and
allocation functionalities of memblock. The main data structure of the boot time
memory allocator is initialized at the build time, so the checks here reuse its
instance throughout the duration of the test. To ensure that tests don't affect
each other, region arrays are reset in between.
As this project uses the actual memblock code and has to run in user space,
some of the kernel definitions were stubbed by the initial commit that
introduced memblock simulator (commit 16802e55dea9 ("memblock tests: Add
skeleton of the memblock simulator")) and a few preparation commits just
before it. Most of them don't match the kernel implementation, so one should
consult them first before making any significant changes to the project.
Usage
=====
To run the tests, build the main target and run it:
$ make && ./main
A successful run produces no output. It is possible to control the behavior
by passing options from command line. For example, to include verbose output,
append the `-v` options when you run the tests:
$ ./main -v
This will print information about which functions are being tested and the
number of test cases that passed.
For the full list of options from command line, see `./main --help`.
It is also possible to override different configuration parameters to change
the test functions. For example, to simulate enabled NUMA, use:
$ make NUMA=1
For the full list of build options, see `make help`.
Project structure
=================
The project has one target, main, which calls a group of checks for basic and
allocation functions. Tests for each group are defined in dedicated files, as it
can be seen here:
memblock
|-- asm ------------------,
|-- lib |-- implement function and struct stubs
|-- linux ------------------'
|-- scripts
| |-- Makefile.include -- handles `make` parameters
|-- tests
| |-- alloc_api.(c|h) -- memblock_alloc tests
| |-- alloc_helpers_api.(c|h) -- memblock_alloc_from tests
| |-- alloc_nid_api.(c|h) -- memblock_alloc_try_nid tests
| |-- basic_api.(c|h) -- memblock_add/memblock_reserve/... tests
| |-- common.(c|h) -- helper functions for resetting memblock;
|-- main.c --------------. dummy physical memory definition
|-- Makefile `- test runner
|-- README
|-- TODO
|-- .gitignore
Simulating physical memory
==========================
Some allocation functions clear the memory in the process, so it is required for
memblock to track valid memory ranges. To achieve this, the test suite registers
with memblock memory stored by test_memory struct. It is a small wrapper that
points to a block of memory allocated via malloc. For each group of allocation
tests, dummy physical memory is allocated, added to memblock, and then released
at the end of the test run. The structure of a test runner checking allocation
functions is as follows:
int memblock_alloc_foo_checks(void)
{
reset_memblock_attributes(); /* data structure reset */
dummy_physical_memory_init(); /* allocate and register memory */
(...allocation checks...)
dummy_physical_memory_cleanup(); /* free the memory */
}
There's no need to explicitly free the dummy memory from memblock via
memblock_free() call. The entry will be erased by reset_memblock_regions(),
called at the beginning of each test.
Known issues
============
1. Tests for memblock_alloc_low() can't be easily implemented. The function uses
ARCH_LOW_ADDRESS_LIMIT marco, which can't be changed to point at the low
memory of the memory_block.
References
==========
1. Boot time memory management documentation page:
https://www.kernel.org/doc/html/latest/core-api/boot-time-mm.html