Lines Matching +full:memory +full:- +full:to +full:- +full:memory

12 or more CPUs, local memory, and/or IO buses.  For brevity and to
17 Each of the 'cells' may be viewed as an SMP [symmetric multi-processor] subset
18 of the system--although some components necessary for a stand-alone SMP system
20 connected together with some sort of system interconnect--e.g., a crossbar or
21 point-to-point link are common types of NUMA system interconnects.  Both of
22 these types of interconnects can be aggregated to create NUMA platforms with
26 Coherent NUMA or ccNUMA systems.   With ccNUMA systems, all memory is visible
27 to and accessible from any CPU attached to any cell and cache coherency
30 Memory access time and effective memory bandwidth varies depending on how far
31 away the cell containing the CPU or IO bus making the memory access is from the
32 cell containing the target memory.  For example, access to memory by CPUs
33 attached to the same cell will experience faster access times and higher
34 bandwidths than accesses to memory on other, remote cells.  NUMA platforms
37 Platform vendors don't build NUMA systems just to make software developers'
38 lives interesting.  Rather, this architecture is a means to provide scalable
39 memory bandwidth.  However, to achieve scalable memory bandwidth, system and
40 application software must arrange for a large majority of the memory references
41 [cache misses] to be to "local" memory--memory on the same cell, if any--or
42 to the closest cell with memory.
44 This leads to the Linux software view of a NUMA system:
50 CPUs, memory and/or IO buses.  And, again, memory accesses to memory on
51 "closer" nodes--nodes that map to closer cells--will generally experience
52 faster access times and higher effective bandwidth than accesses to more
56 physical cell that has no memory attached, and reassign any CPUs attached to
57 that cell to a node representing a cell that does have memory.  Thus, on
59 a given node will see the same local memory access times and bandwidth.
63 the existing nodes--or the system memory for non-NUMA platforms--into multiple
65 physical memory.  NUMA emulation is useful for testing NUMA kernel and
66 application features on non-NUMA platforms, and as a sort of memory resource
68 [see Documentation/admin-guide/cgroup-v1/cpusets.rst]
70 For each node with memory, Linux constructs an independent memory management
71 subsystem, complete with its own free page lists, in-use page lists, usage
72 statistics and locks to mediate access.  In addition, Linux constructs for
73 each memory zone [one or more of DMA, DMA32, NORMAL, HIGH_MEMORY, MOVABLE],
74 an ordered "zonelist".  A zonelist specifies the zones/nodes to visit when a
76 when a zone has no available memory to satisfy a request, is called
80 memory, Linux must decide whether to order the zonelists such that allocations
81 fall back to the same zone type on a different node, or to a different zone
84 a default Node ordered zonelist. This means it tries to fallback to other zones
87 By default, Linux will attempt to satisfy memory allocation requests from the
88 node to which the CPU that executes the request is assigned.  Specifically,
89 Linux will attempt to allocate from the first node in the appropriate zonelist
95 Local allocation will tend to keep subsequent access to the allocated memory
96 "local" to the underlying physical resources and off the system interconnect--
97 as long as the task on whose behalf the kernel allocated some memory does not
98 later migrate away from that memory.  The Linux scheduler is aware of the
99 NUMA topology of the platform--embodied in the "scheduling domains" data
100 structures [see Documentation/scheduler/sched-domains.rst]--and the scheduler
101 attempts to minimize task migration to distant scheduling domains.  However,
107 to improve NUMA locality using various CPU affinity command line interfaces,
110 allocation behavior using Linux NUMA memory policy. [see
111 Documentation/admin-guide/mm/numa_memory_policy.rst].
113 System administrators can restrict the CPUs and nodes' memories that a non-
115 using control groups and CPUsets.  [see Documentation/admin-guide/cgroup-v1/cpusets.rst]
118 zones [nodes] with memory in the zonelists.  This means that for a memoryless
119 node the "local memory node"--the node of the first zone in CPU's node's
120 zonelist--will not be the node itself.  Rather, it will be the node that the
121 kernel selected as the nearest node with memory when it built the zonelists.
123 closest available memory.  This is a consequence of the same mechanism that
124 allows such allocations to fallback to other nearby nodes when a node that
125 does contain memory overflows.
128 behavior.  Rather they want to be sure they get memory from the specified node
129 or get notified that the node has no free memory.  This is usually the case when
130 a subsystem allocates per CPU memory resources, for example.
132 A typical model for making such an allocation is to obtain the node id of the
133 node to which the "current CPU" is attached using one of the kernel's
134 numa_node_id() or CPU_to_node() functions and then request memory from only
136 may revert to its own fallback path.  The slab kernel memory allocator is an
137 example of this.  Or, the subsystem may choose to disable or not to enable
141 If the architecture supports--does not hide--memoryless nodes, then CPUs
142 attached to memoryless nodes would always incur the fallback path overhead
143 or some subsystems would fail to initialize if they attempted to allocated
144 memory exclusively from a node without memory.  To support such
146 or cpu_to_mem() function to locate the "local memory node" for the calling or