| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20080204174054.DDC221FE109@attica.americas.sgi.com> Date: Mon, 04 Feb 2008 11:40:54 -0600 From: cpw@....com (Cliff Wickman) To: linux-kernel@...r.kernel.org Cc: pj@....com, menage@...gle.com, akpm@...l.org Subject: [PATCH 3/4 v2] cpusets: update_cpumask documentation fix 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@....com> Acked-by: Cliff Wickman <cpw@....com> --- Documentation/cpusets.txt | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) Index: linux-2.6/Documentation/cpusets.txt =================================================================== --- linux-2.6.orig/Documentation/cpusets.txt +++ linux-2.6/Documentation/cpusets.txt @@ -523,21 +523,14 @@ from one cpuset to another, then the ker 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, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists