aboutsummaryrefslogtreecommitdiffstats
path: root/fs/vfat
diff options
context:
space:
mode:
authorPaul Jackson <pj@sgi.com>2006-03-31 02:30:52 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2006-03-31 12:18:55 -0800
commite4e364e865b382f9d99c7fc230ec2ce7df21257a (patch)
tree9ff5ab54a0e40d7ad2b55d3ec48c6e175ebf50c7 /fs/vfat
parent[PATCH] cpuset: unsafe mm reference fix (diff)
downloadlinux-dev-e4e364e865b382f9d99c7fc230ec2ce7df21257a.tar.xz
linux-dev-e4e364e865b382f9d99c7fc230ec2ce7df21257a.zip
[PATCH] cpuset: memory migration interaction fix
Fix memory migration so that it works regardless of what cpuset the invoking task is in. If a task invoked a memory migration, by doing one of: 1) writing a different nodemask to a cpuset 'mems' file, or 2) writing a tasks pid to a different cpuset's 'tasks' file, where the cpuset had its 'memory_migrate' option turned on, then the allocation of the new pages for the migrated task(s) was constrained by the invoking tasks cpuset. If this task wasn't in a cpuset that allowed the requested memory nodes, the memory migration would happen to some other nodes that were in that invoking tasks cpuset. This was usually surprising and puzzling behaviour: Why didn't the pages move? Why did the pages move -there-? To fix this, temporarilly change the invoking tasks 'mems_allowed' task_struct field to the nodes the migrating tasks is moving to, so that new pages can be allocated there. Signed-off-by: Paul Jackson <pj@sgi.com> Acked-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/vfat')
0 files changed, 0 insertions, 0 deletions