Lines Matching +full:in +full:- +full:memory
1 .. SPDX-License-Identifier: GPL-2.0
4 Physical Memory
8 architecture-independent abstraction to represent the physical memory. This
9 chapter describes the structures used to manage physical memory in a running
12 The first principal concept prevalent in the memory management is
13 `Non-Uniform Memory Access (NUMA)
14 <https://en.wikipedia.org/wiki/Non-uniform_memory_access>`_.
15 With multi-core and multi-socket machines, memory may be arranged into banks
17 processor. For example, there might be a bank of memory assigned to each CPU or
18 a bank of memory very suitable for DMA near peripheral devices.
28 locally on the memory bank they represent. For UMA architectures, only one
30 be discussed further in Section :ref:`Nodes <nodes>`
33 called zones which represent ranges within memory. These ranges are usually
34 determined by architectural constraints for accessing the physical memory.
35 The memory range within a node that corresponds to a particular zone is
39 * ``ZONE_DMA`` and ``ZONE_DMA32`` historically represented memory suitable for
41 memory. For many years there are better more and robust interfaces to get
42 memory with DMA specific requirements (Documentation/core-api/dma-api.rst),
43 but ``ZONE_DMA`` and ``ZONE_DMA32`` still represent memory ranges that have
47 ``CONFIG_ZONE_DMA32`` configuration options. Some 64-bit platforms may need
51 * ``ZONE_NORMAL`` is for normal memory that can be accessed by the kernel all
52 the time. DMA operations can be performed on pages in this zone if the DMA
53 devices support transfers to all addressable memory. ``ZONE_NORMAL`` is
56 * ``ZONE_HIGHMEM`` is the part of the physical memory that is not covered by a
57 permanent mapping in the kernel page tables. The memory in this zone is only
59 only on some 32-bit architectures and is enabled with ``CONFIG_HIGHMEM``.
61 * ``ZONE_MOVABLE`` is for normal accessible memory, just like ``ZONE_NORMAL``.
62 The difference is that the contents of most pages in ``ZONE_MOVABLE`` is
65 ``ZONE_MOVABLE`` is populated during memory hotplug, but it may be
69 Documentation/admin-guide/mm/memory-hotplug.rst for additional details.
71 * ``ZONE_DEVICE`` represents memory residing on devices such as PMEM and GPU.
73 :ref:`struct page <Pages>` and memory map services for device driver
79 discussed further in Section :ref:`Zones <zones>`.
81 The relation between node and zone extents is determined by the physical memory
82 map reported by the firmware, architectural constraints for memory addressing
83 and certain parameters in the kernel command line.
85 For example, with 32-bit kernel on an x86 UMA machine with 2 Gbytes of RAM the
86 entire memory will be on node 0 and there will be three zones: ``ZONE_DMA``,
90 +-------------------------------------------------------------+
92 +-------------------------------------------------------------+
95 +----------+-----------------------+--------------------------+
97 +----------+-----------------------+--------------------------+
108 +--------------------------------+ +--------------------------+
110 +--------------------------------+ +--------------------------+
113 +---------+----------+-----------+ +------------+-------------+
115 +---------+----------+-----------+ +------------+-------------+
118 Memory banks may belong to interleaving nodes. In the example below an x86
119 machine has 16 Gbytes of RAM in 4 memory banks, even banks belong to node 0
124 +-------------+ +-------------+ +-------------+ +-------------+
126 +-------------+ +-------------+ +-------------+ +-------------+
129 +-----+-------+ +-------------+ +-------------+ +-------------+
131 +-----+-------+ +-------------+ +-------------+ +-------------+
133 In this case node 0 will span from 0 to 12 Gbytes and node 1 will span from
141 As we have mentioned, each node in memory is described by a ``pg_data_t`` which
143 Linux uses a node-local allocation policy to allocate memory from the node
145 likely the memory from the current node will be used. The allocation policy can
146 be controlled by users as described in
147 Documentation/admin-guide/mm/numa_memory_policy.rst.
151 architecture specific code parses the physical memory map reported by the
152 firmware. The bulk of the node initialization happens slightly later in the
153 boot process by free_area_init() function, described later in Section
158 bitmasks called ``node_states``. Each bitmask in this array represents a set of
166 The node has regular memory.
168 The node has regular or high memory. When ``CONFIG_HIGHMEM`` is disabled
171 The node has memory(regular, high, movable)
176 node ID in the ``node_states[<property>]`` bitmask is set.
178 For example, for node 2 with normal memory and CPUs, bit 2 will be set in ::
202 --------------
204 The nodes structure ``struct pglist_data`` is declared in
217 The list of all zones in all nodes. This list defines the order of zones
219 ``build_zonelists()`` in ``mm/page_alloc.c`` during the initialization of
220 core memory management structures.
223 Number of populated zones in this node.
226 For UMA systems that use FLATMEM memory model the 0's node
230 For UMA systems that use FLATMEM memory model the 0's node
232 in the kernels built with ``CONFIG_PAGE_EXTENSION`` enabled.
235 The page frame number of the starting page frame in this node.
238 Total number of physical pages present in this node.
255 This is a per-node reserve of pages that are not available to userspace
259 If memory initialization on large machines is deferred then this is the first
264 …Per-node queue of huge pages that their split was deferred. Defined only when ``CONFIG_TRANSPARENT…
267 Per-node lruvec holding LRU lists and related parameters. Used only when
268 memory cgroups are disabled. It should not be accessed directly, use
277 Per-node instance of kswapd kernel thread.
280 Workqueues used to synchronize memory reclaim tasks
319 Workqueue used to synchronize memory compaction tasks.
322 Per-node instance of kcompactd kernel thread.
332 Per-CPU VM statistics for the node