| .. | .. |
|---|
| 15 | 15 | support. |
|---|
| 16 | 16 | |
|---|
| 17 | 17 | Memory policies should not be confused with cpusets |
|---|
| 18 | | -(``Documentation/cgroup-v1/cpusets.txt``) |
|---|
| 18 | +(``Documentation/admin-guide/cgroup-v1/cpusets.rst``) |
|---|
| 19 | 19 | which is an administrative mechanism for restricting the nodes from which |
|---|
| 20 | 20 | memory may be allocated by a set of processes. Memory policies are a |
|---|
| 21 | 21 | programming interface that a NUMA-aware application can take advantage of. When |
|---|
| .. | .. |
|---|
| 364 | 364 | |
|---|
| 365 | 365 | 2) for querying the policy, we do not need to take an extra reference on the |
|---|
| 366 | 366 | target task's task policy nor vma policies because we always acquire the |
|---|
| 367 | | - task's mm's mmap_sem for read during the query. The set_mempolicy() and |
|---|
| 368 | | - mbind() APIs [see below] always acquire the mmap_sem for write when |
|---|
| 367 | + task's mm's mmap_lock for read during the query. The set_mempolicy() and |
|---|
| 368 | + mbind() APIs [see below] always acquire the mmap_lock for write when |
|---|
| 369 | 369 | installing or replacing task or vma policies. Thus, there is no possibility |
|---|
| 370 | 370 | of a task or thread freeing a policy while another task or thread is |
|---|
| 371 | 371 | querying it. |
|---|
| 372 | 372 | |
|---|
| 373 | 373 | 3) Page allocation usage of task or vma policy occurs in the fault path where |
|---|
| 374 | | - we hold them mmap_sem for read. Again, because replacing the task or vma |
|---|
| 375 | | - policy requires that the mmap_sem be held for write, the policy can't be |
|---|
| 374 | + we hold them mmap_lock for read. Again, because replacing the task or vma |
|---|
| 375 | + policy requires that the mmap_lock be held for write, the policy can't be |
|---|
| 376 | 376 | freed out from under us while we're using it for page allocation. |
|---|
| 377 | 377 | |
|---|
| 378 | 378 | 4) Shared policies require special consideration. One task can replace a |
|---|
| 379 | | - shared memory policy while another task, with a distinct mmap_sem, is |
|---|
| 379 | + shared memory policy while another task, with a distinct mmap_lock, is |
|---|
| 380 | 380 | querying or allocating a page based on the policy. To resolve this |
|---|
| 381 | 381 | potential race, the shared policy infrastructure adds an extra reference |
|---|
| 382 | 382 | to the shared policy during lookup while holding a spin lock on the shared |
|---|