Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 83811
b: refs/heads/master
c: 8f5aa26
h: refs/heads/master
i:
  83809: 0484507
  83807: bd508a1
v: v3
  • Loading branch information
Paul Jackson authored and Linus Torvalds committed Feb 7, 2008
1 parent b34fd97 commit 86ae994
Show file tree
Hide file tree
Showing 2 changed files with 9 additions and 16 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 73507f335f406ff31ceb97b39fa76eaee00f4f26
refs/heads/master: 8f5aa26c75b7722e80c0c5c5bb833d41865d7019
23 changes: 8 additions & 15 deletions trunk/Documentation/cpusets.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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
to allocate a page of memory for that task.

If a cpuset has its CPUs modified, then each task using that
cpuset does _not_ change its behavior automatically. In order to
minimize the impact on the critical scheduling code in the kernel,
tasks will continue to use their prior CPU placement until they
are rebound to their cpuset, by rewriting their pid to the 'tasks'
file of their cpuset. If a task had been bound to some subset of its
cpuset using the sched_setaffinity() call, and if any of that subset
is still allowed in its new cpuset settings, then the task will be
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.
If a cpuset has its 'cpus' modified, then each task in that cpuset
will have its allowed CPU placement changed immediately. Similarly,
if a tasks pid is written to a cpusets 'tasks' file, in either its
current cpuset or another cpuset, then its allowed CPU placement is
changed immediately. If such a task had been bound to some subset
of its cpuset using the sched_setaffinity() call, the task will be
allowed to run on any CPU allowed in its new cpuset, negating the
affect of the prior sched_setaffinity() call.

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,
Expand Down

0 comments on commit 86ae994

Please sign in to comment.