From 86ae9944514484aed1a4f5c54f62bf89c8e53819 Mon Sep 17 00:00:00 2001 From: Paul Jackson Date: Thu, 7 Feb 2008 00:14:48 -0800 Subject: [PATCH] --- yaml --- r: 83811 b: refs/heads/master c: 8f5aa26c75b7722e80c0c5c5bb833d41865d7019 h: refs/heads/master i: 83809: 0484507d048a6596df1c6f569b27ce1d9408ceb6 83807: bd508a1ad37c2bc9db9f5872411d4d56e3b57fdf v: v3 --- [refs] | 2 +- trunk/Documentation/cpusets.txt | 23 ++++++++--------------- 2 files changed, 9 insertions(+), 16 deletions(-) diff --git a/[refs] b/[refs] index 0b81fc1b2246..1bc3c1103af2 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 73507f335f406ff31ceb97b39fa76eaee00f4f26 +refs/heads/master: 8f5aa26c75b7722e80c0c5c5bb833d41865d7019 diff --git a/trunk/Documentation/cpusets.txt b/trunk/Documentation/cpusets.txt index 141bef1c8599..43db6fe12814 100644 --- a/trunk/Documentation/cpusets.txt +++ b/trunk/Documentation/cpusets.txt @@ -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,