Documentation/vm/numa_memory_policy.txt

2 What is Linux Memory Policy?
4 In the Linux kernel, "memory policy" determines from which node the kernel will
5 allocate memory in a NUMA system or in an emulated NUMA system.  Linux has
6 supported platforms with Non-Uniform Memory Access architectures since 2.4.?.
7 The current memory policy support was added to Linux 2.6 around May 2004.  This
8 document attempts to describe the concepts and APIs of the 2.6 memory policy
11 Memory policies should not be confused with cpusets
14 memory may be allocated by a set of processes. Memory policies are a
17 takes priority.  See "MEMORY POLICIES AND CPUSETS" below for more details.
19 MEMORY POLICY CONCEPTS
21 Scope of Memory Policies
23 The Linux kernel supports _scopes_ of memory policy, described here from
32     with "sufficient" memory, so as not to overload the initial boot node
46 	executable image that has no awareness of memory policy.  See the
47 	MEMORY POLICY APIS section, below, for an overview of the system call
61     VMA Policy:  A "VMA" or "Virtual Memory Area" refers to a range of a task's
63     of its virtual address space.   See the MEMORY POLICIES APIS section,
93 	memory area into 2 or 3 VMAs, each with it's own policy.
102     Shared Policy:  Conceptually, shared policies apply to "memory objects"
112 	As of 2.6.22, only shared memory segments, created by shmget() or
131 	Thus, different tasks that attach to a shared memory segment can have
134 	a shared memory region, when one task has installed shared policy on
137 Components of Memory Policies
139     A Linux memory policy consists of a "mode", optional mode flags, and an
145    Internally, memory policies are implemented by a reference counted
149    Linux memory policy supports the following 4 behavioral modes:
151 	Default Mode--MPOL_DEFAULT:  This mode is only used in the memory
153 	memory policy in all policy scopes.  Any existing non-default policy
161 	    When specified in one of the memory policy APIs, the Default mode
167 	MPOL_BIND:  This mode specifies that memory must come from the
168 	set of nodes specified by the policy.  Memory will be allocated from
169 	the node in the set with sufficient free memory that is closest to
197 	    For allocation of anonymous pages and shared memory pages,
216    Linux memory policy supports the following optional mode flags:
220 	nodes changes after the memory policy has been defined.
229 	    nodes allowed by the task's cpuset, then the memory policy is
283 	    nodemasks to specify memory policies using this flag should
284 	    disregard their current, actual cpuset imposed memory placement
286 	    memory nodes 0 to N-1, where N is the number of memory nodes the
288 	    set of memory nodes allowed by the task's cpuset, as that may
296 MEMORY POLICY REFERENCE COUNTING
304 When a new memory policy is allocated, its reference count is initialized
306 new policy.  When a pointer to a memory policy structure is stored in another
344    shared memory policy while another task, with a distinct mmap_sem, is
358    true for shared policies on shared memory regions shared by tasks running
360    falling back to task or system default policy for shared memory regions,
361    or by prefaulting the entire shared memory region into memory and locking
364 MEMORY POLICY APIs
366 Linux supports 3 system calls for controlling memory policy.  These APIS
376 Set [Task] Memory Policy:
381 	Set's the calling task's "task/process memory policy" to mode
391 Get [Task] Memory Policy or Related Information
397 	Queries the "task/process memory policy" of the calling task, or
417 MEMORY POLICY COMMAND LINE INTERFACE
419 Although not strictly part of the Linux implementation of memory policy,
425 + set the shared policy for a shared memory segment via mbind(2)
428 containing the memory policy system call wrappers.  Some distributions
433 MEMORY POLICIES AND CPUSETS
435 Memory policies work within cpusets as described above.  For memory policies
440 specified for the policy and the set of nodes with memory is used.  If the
445 The interaction of memory policies and cpusets can be problematic when tasks
446 in two cpusets share access to a memory region, such as shared memory segments
450 this information requires "stepping outside" the memory policy APIs to use the
453 memory sets are disjoint, "local" allocation is the only valid policy.