Lines Matching refs:policy
4 In the Linux kernel, "memory policy" determines from which node the kernel will
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
23 The Linux kernel supports _scopes_ of memory policy, described here from
26 System Default Policy: this policy is "hard coded" into the kernel. It
27 is the policy that governs all page allocations that aren't controlled
28 by one of the more specific policy scopes discussed below. When the
29 system is "up and running", the system default policy will use "local
31 default policy will be set to interleave allocations across all nodes
35 Task/Process Policy: this is an optional, per-task policy. When defined
36 for a specific task, this policy controls all page allocations made by or
38 If a task does not define a task policy, then all page allocations that
39 would have been controlled by the task policy "fall back" to the System
42 The task policy applies to the entire address space of a task. Thus,
45 to establish the task policy for a child task exec()'d from an
46 executable image that has no awareness of memory policy. See the
48 that a task may use to set/change its task/process policy.
51 [Linux kernel task] that installs the policy and any threads
53 at the time a new task policy is installed retain their current
54 policy.
56 A task policy applies only to pages allocated after the policy is
58 changes its task policy remain where they were allocated based on
59 the policy at the time they were allocated.
62 virtual address space. A task may define a specific policy for a range
65 policy.
67 A VMA policy will govern the allocation of pages that back this region of
69 have an explicit VMA policy will fall back to the task policy, which may
74 VMA policy applies ONLY to anonymous pages. These include pages
77 If a VMA policy is applied to a file mapping, it will be ignored if
79 MAP_PRIVATE flag, the VMA policy will only be applied when an
84 space--a.k.a. threads--independent of when the policy is installed; and
91 A task may install a new VMA policy on a sub-range of a previously
93 memory area into 2 or 3 VMAs, each with it's own policy.
95 By default, VMA policy applies only to pages allocated after the policy
97 where they were allocated based on the policy at the time they were
100 a newly installed policy.
109 object share the policy, and all pages allocated for the shared object,
110 by any task, will obey the shared policy.
113 mmap(MAP_ANONYMOUS|MAP_SHARED), support shared policy. When shared
114 policy support was added to Linux, the associated data structures were
117 shmem segments were never "hooked up" to the shared policy support.
119 for shared policy has not been completed.
123 policy installed on the virtual address range backed by the shared
126 task policy, if any, else System Default Policy.
128 The shared policy infrastructure supports different policies on subset
130 the task that installs the policy for each range of distinct policy.
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
140 optional set of nodes. The mode determines the behavior of the policy,
142 optional set of nodes can be viewed as the arguments to the policy
149 Linux memory policy supports the following 4 behavioral modes:
152 policy APIs. Internally, MPOL_DEFAULT is converted to the NULL
153 memory policy in all policy scopes. Any existing non-default policy
155 MPOL_DEFAULT means "fall back to the next most specific policy scope."
157 For example, a NULL or default task policy will fall back to the
158 system default policy. A NULL or default vma policy will fall
159 back to the task policy.
161 When specified in one of the memory policy APIs, the Default mode
164 It is an error for the set of nodes specified for this policy to
168 set of nodes specified by the policy. Memory will be allocated from
173 attempted from the single node specified in the policy. If that
178 Internally, the Preferred policy uses a single node--the
181 the policy is interpreted as local allocation. "Local" allocation
182 policy can be viewed as a Preferred policy that starts at the node
187 If an empty nodemask is passed, the policy cannot use the
193 the policy. This mode also behaves slightly differently, based on
197 Interleave mode indexes the set of nodes specified by the policy
200 by the policy. It then attempts to allocate a page, starting at
202 policy or had been selected by a local allocation. That is,
206 of nodes specified by the policy using a node counter maintained
209 spread the pages out over the nodes specified by the policy based
212 the temporary interleaved system default policy works in this
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
230 overlap, the Default policy is used.
233 mems 1-3 that sets an Interleave policy over the same set. If
263 nodemask, the policy will be effected over the first (and in the
275 mems 2-5 that sets an Interleave policy over the same set with
286 policy is intended to manage. Let the kernel then remap to the
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
307 on completion of the policy installation.
309 During run-time "usage" of the policy, we attempt to minimize atomic operations
313 1) querying of the policy, either by the task itself [using the get_mempolicy()
317 2) examination of the policy to determine the policy mode and associated node
321 BIND policy nodemask is used, by reference, to filter ineligible nodes.
326 1) we never need to get/free the system default policy as this is never
329 2) for querying the policy, we do not need to take an extra reference on the
330 target task's task policy nor vma policies because we always acquire the
334 of a task or thread freeing a policy while another task or thread is
337 3) Page allocation usage of task or vma policy occurs in the fault path where
339 policy requires that the mmap_sem be held for write, the policy can't be
343 shared memory policy while another task, with a distinct mmap_sem, is
344 querying or allocating a page based on the policy. To resolve this
345 potential race, the shared policy infrastructure adds an extra reference
346 to the shared policy during lookup while holding a spin lock on the shared
347 policy management structure. This requires that we drop this extra
348 reference when we're finished "using" the policy. We must drop the
359 falling back to task or system default policy for shared memory regions,
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
397 the policy or location of a specified virtual address, depending
409 mbind() installs the policy specified by (mode, nmask, maxnodes) as
410 a VMA policy for the range of the calling task's address space
418 Although not strictly part of the Linux implementation of memory policy,
421 + set the task policy for a specified program via set_mempolicy(2), fork(2) and
424 + set the shared policy for a shared memory segment via mbind(2)
427 containing the memory policy system call wrappers. Some distributions
437 specified for the policy contains nodes that are not allowed by the cpuset and
439 specified for the policy and the set of nodes with memory is used. If the
440 result is the empty set, the policy is considered invalid and cannot be
441 installed. If MPOL_F_RELATIVE_NODES is used, the policy's nodes are mapped
447 any of the tasks install shared policy on the region, only nodes whose
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.