mk-rootfs.sh

hc

2023-12-11 072de836f53be56a70cecf70b43ae43b7ce17376

 kernel/Documentation/admin-guide/mm/numa_memory_policy.rst
..
..
@@ -15,7 +15,7 @@
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,19 +364,19 @@
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