diff options
author | Paul Jackson <pj@sgi.com> | 2006-03-31 02:30:52 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-03-31 12:18:55 -0800 |
commit | e4e364e865b382f9d99c7fc230ec2ce7df21257a (patch) | |
tree | 9ff5ab54a0e40d7ad2b55d3ec48c6e175ebf50c7 /fs/vfat | |
parent | 2741a559a01e1ba9bf87285569dc1a104d134ecf (diff) | |
download | linux-3.10-e4e364e865b382f9d99c7fc230ec2ce7df21257a.tar.gz linux-3.10-e4e364e865b382f9d99c7fc230ec2ce7df21257a.tar.bz2 linux-3.10-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