leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

cpusets: update_cpumask documentation fix

Browse Source 
Update cpuset documentation to match the October 2007 "Fix cpusets
update_cpumask" changes that now apply changes to a cpusets 'cpus' allowed
mask immediately to the cpus_allowed of the tasks in that cpuset.

Signed-off-by: Paul Jackson <pj@sgi.com>
Acked-by: Cliff Wickman <cpw@sgi.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Paul Jackson 2008-02-07 00:14:48 -08:00 committed by Linus Torvalds
parent 73507f335f
commit 8f5aa26c75
1 changed files with 8 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
Documentation/cpusets.txt
View File

@ -523,21 +523,14 @@ from one cpuset to another, then the kernel will adjust the tasks
memory placement, as above, the next time that the kernel attempts memory placement, as above, the next time that the kernel attempts
to allocate a page of memory for that task. to allocate a page of memory for that task.
If a cpuset has its CPUs modified, then each task using that If a cpuset has its 'cpus' modified, then each task in that cpuset
cpuset does _not_ change its behavior automatically. In order to will have its allowed CPU placement changed immediately. Similarly,
minimize the impact on the critical scheduling code in the kernel, if a tasks pid is written to a cpusets 'tasks' file, in either its
tasks will continue to use their prior CPU placement until they current cpuset or another cpuset, then its allowed CPU placement is
are rebound to their cpuset, by rewriting their pid to the 'tasks' changed immediately. If such a task had been bound to some subset
file of their cpuset. If a task had been bound to some subset of its of its cpuset using the sched_setaffinity() call, the task will be
cpuset using the sched_setaffinity() call, and if any of that subset allowed to run on any CPU allowed in its new cpuset, negating the
is still allowed in its new cpuset settings, then the task will be affect of the prior sched_setaffinity() call.
restricted to the intersection of the CPUs it was allowed on before,
and its new cpuset CPU placement. If, on the other hand, there is
no overlap between a tasks prior placement and its new cpuset CPU
placement, then the task will be allowed to run on any CPU allowed
in its new cpuset. If a task is moved from one cpuset to another,
its CPU placement is updated in the same way as if the tasks pid is
rewritten to the 'tasks' file of its current cpuset.
In summary, the memory placement of a task whose cpuset is changed is In summary, the memory placement of a task whose cpuset is changed is
updated by the kernel, on the next allocation of a page for that task, updated by the kernel, on the next allocation of a page for that task,