Lines Matching full:memory

6 Physical Memory Model
9 Physical memory in a system may be addressed in different ways. The
10 simplest case is when the physical memory starts at address 0 and
15 different memory banks are attached to different CPUs.
17 Linux abstracts this diversity using one of the three memory models:
19 memory models it supports, what the default memory model is and
26 All the memory models track the status of physical page frames using
29 Regardless of the selected memory model, there exists one-to-one
33 Each memory model defines :c:func:`pfn_to_page` and :c:func:`page_to_pfn`
40 The simplest memory model is FLATMEM. This model is suitable for
42 memory.
44 In the FLATMEM memory model, there is a global `mem_map` array that
45 maps the entire physical memory. For most architectures, the holes
53 the memory to the page allocator.
66 systems with physical memory starting at address different from 0.
71 The DISCONTIGMEM model treats the physical memory as a collection of
73 constructs an independent memory management subsystem represented by
108 SPARSEMEM is the most versatile memory model available in Linux and it
109 is the only memory model that supports several advanced features such
110 as hot-plug and hot-remove of the physical memory, alternative memory
111 maps for non-volatile memory devices and deferred initialization of
112 the memory map for larger systems.
114 The SPARSEMEM model presents the physical memory as a collection of
143   all the memory sections.
146 each active memory range or use :c:func:`memblocks_present` or
148 initialize the memory sections. Next, the actual memory maps should be
160 The sparse vmemmap uses a virtually mapped memory map to optimize
168 addresses that will map the physical pages containing the memory
171 that will allocate the physical memory and create page tables for the
172 virtual memory map. If an architecture does not have any special
174 :c:func:`vmemmap_populate_basepages` provided by the generic memory
177 The virtually mapped memory map allows storing `struct page` objects
178 for persistent memory devices in pre-allocated storage on those
183 allocate memory map on the persistent memory device.
192 to keep the memory pinned for active use. `ZONE_DEVICE`, via
193 :c:func:`devm_memremap_pages`, performs just enough memory hotplug to
197 free memory and the page's `struct list_head lru` space is repurposed
198 for back referencing to the host device / driver that mapped the memory.
200 While `SPARSEMEM` presents memory as a collection of sections,
201 optionally collected into memory blocks, `ZONE_DEVICE` users have a need
203 `ZONE_DEVICE` memory is never marked online it is subsequently never
204 subject to its memory ranges being exposed through the sysfs memory
205 hotplug api on memory block boundaries. The implementation relies on
206 this lack of user-api constraint to allow sub-section sized memory
208 memory hotplug. Sub-section support allows for 2MB as the cross-arch
213 * pmem: Map platform persistent memory to be used as a direct-I/O target
217   event callbacks to allow a device-driver to coordinate memory management
218   events related to device-memory, typically GPU memory. See
223   i.e. bypass host memory.