Lines Matching +full:in +full:- +full:memory
1 .. SPDX-License-Identifier: GPL-2.0
4 Physical Memory Model
7 Physical memory in a system may be addressed in different ways. The
8 simplest case is when the physical memory starts at address 0 and
13 different memory banks are attached to different CPUs.
15 Linux abstracts this diversity using one of the two memory models:
17 memory models it supports, what the default memory model is and
20 All the memory models track the status of physical page frames using
21 struct page arranged in one or more arrays.
23 Regardless of the selected memory model, there exists one-to-one
27 Each memory model defines :c:func:`pfn_to_page` and :c:func:`page_to_pfn`
34 The simplest memory model is FLATMEM. This model is suitable for
35 non-NUMA systems with contiguous, or mostly contiguous, physical
36 memory.
38 In the FLATMEM memory model, there is a global `mem_map` array that
39 maps the entire physical memory. For most architectures, the holes
40 have entries in the `mem_map` array. The `struct page` objects
46 memory to the page allocator.
49 actual physical pages. In such case, the architecture specific
50 :c:func:`pfn_valid` implementation should take the holes in the
54 straightforward: `PFN - ARCH_PFN_OFFSET` is an index to the
58 systems with physical memory starting at address different from 0.
63 SPARSEMEM is the most versatile memory model available in Linux and it
64 is the only memory model that supports several advanced features such
65 as hot-plug and hot-remove of the physical memory, alternative memory
66 maps for non-volatile memory devices and deferred initialization of
67 the memory map for larger systems.
69 The SPARSEMEM model presents the physical memory as a collection of
85 NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)}
87 The `mem_section` objects are arranged in a two-dimensional array
98 all the memory sections.
101 initialize the memory sections and the memory maps.
104 corresponding `struct page` - a "classic sparse" and "sparse
108 The classic sparse encodes the section number of a page in page->flags
112 The sparse vmemmap uses a virtually mapped memory map to optimize
120 addresses that will map the physical pages containing the memory
121 map and make sure that `vmemmap` points to that range. In addition,
123 that will allocate the physical memory and create page tables for the
124 virtual memory map. If an architecture does not have any special
126 :c:func:`vmemmap_populate_basepages` provided by the generic memory
129 The virtually mapped memory map allows storing `struct page` objects
130 for persistent memory devices in pre-allocated storage on those
135 allocate memory map on the persistent memory device.
144 to keep the memory pinned for active use. `ZONE_DEVICE`, via
145 :c:func:`devm_memremap_pages`, performs just enough memory hotplug to
149 free memory and the page's `struct list_head lru` space is repurposed
150 for back referencing to the host device / driver that mapped the memory.
152 While `SPARSEMEM` presents memory as a collection of sections,
153 optionally collected into memory blocks, `ZONE_DEVICE` users have a need
155 `ZONE_DEVICE` memory is never marked online it is subsequently never
156 subject to its memory ranges being exposed through the sysfs memory
157 hotplug api on memory block boundaries. The implementation relies on
158 this lack of user-api constraint to allow sub-section sized memory
159 ranges to be specified to :c:func:`arch_add_memory`, the top-half of
160 memory hotplug. Sub-section support allows for 2MB as the cross-arch
165 * pmem: Map platform persistent memory to be used as a direct-I/O target
168 * hmm: Extend `ZONE_DEVICE` with `->page_fault()` and `->page_free()`
169 event callbacks to allow a device-driver to coordinate memory management
170 events related to device-memory, typically GPU memory. See
173 * p2pdma: Create `struct page` objects to allow peer devices in a
174 PCI/-E topology to coordinate direct-DMA operations between themselves,
175 i.e. bypass host memory.