tools/testing/memblock/README
Source file repositories/reference/linux-study-clean/tools/testing/memblock/README
File Facts
- System
- Linux kernel
- Corpus path
tools/testing/memblock/README- Extension
[no extension]- Size
- 4423 bytes
- Lines
- 116
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: tools
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
function memblock_alloc_foo_checks
Annotated Snippet
==================
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
Annotation
- Detected declarations: `function memblock_alloc_foo_checks`.
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.