Lines Matching refs:memory
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
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
14 memory may be allocated by a set of processes. Memory policies are a
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
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
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
169 the node in the set with sufficient free memory that is closest to
196 For allocation of anonymous pages and shared memory pages,
215 Linux memory policy supports the following optional mode flags:
219 nodes changes after the memory policy has been defined.
228 nodes allowed by the task's cpuset, then the memory policy is
282 nodemasks to specify memory policies using this flag should
283 disregard their current, actual cpuset imposed memory placement
285 memory nodes 0 to N-1, where N is the number of memory nodes the
287 set of memory nodes allowed by the task's cpuset, as that may
303 When a new memory policy is allocated, its reference count is initialized
305 new policy. When a pointer to a memory policy structure is stored in another
343 shared memory policy while another task, with a distinct mmap_sem, is
357 true for shared policies on shared memory regions shared by tasks running
359 falling back to task or system default policy for shared memory regions,
360 or by prefaulting the entire shared memory region into memory and locking
365 Linux supports 3 system calls for controlling memory policy. These APIS
380 Set's the calling task's "task/process memory policy" to mode
396 Queries the "task/process memory policy" of the calling task, or
418 Although not strictly part of the Linux implementation of memory policy,
424 + set the shared policy for a shared memory segment via mbind(2)
427 containing the memory policy system call wrappers. Some distributions
434 Memory policies work within cpusets as described above. For memory policies
439 specified for the policy and the set of nodes with memory is used. If the
444 The interaction of memory policies and cpusets can be problematic when tasks
445 in two cpusets share access to a memory region, such as shared memory segments
449 this information requires "stepping outside" the memory policy APIs to use the
452 memory sets are disjoint, "local" allocation is the only valid policy.