summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorRik van Riel <riel@redhat.com>2014-04-11 21:00:29 +0400
committerIngo Molnar <mingo@kernel.org>2014-05-07 15:33:47 +0400
commit68d1b02a58f5d9f584c1fb2923ed60ec68cbbd9b (patch)
tree3a2c4afeca2dd9403a3e7e9d646d9067f4bf7d1d /mm
parent5085e2a328849bdee6650b32d52c87c3788ab01c (diff)
downloadlinux-68d1b02a58f5d9f584c1fb2923ed60ec68cbbd9b.tar.xz
sched/numa: Do not set preferred_node on migration to a second choice node
Setting the numa_preferred_node for a task in task_numa_migrate does nothing on a 2-node system. Either we migrate to the node that already was our preferred node, or we stay where we were. On a 4-node system, it can slightly decrease overhead, by not calling the NUMA code as much. Since every node tends to be directly connected to every other node, running on the wrong node for a while does not do much damage. However, on an 8 node system, there are far more bad nodes than there are good ones, and pretending that a second choice is actually the preferred node can greatly delay, or even prevent, a workload from converging. The only time we can safely pretend that a second choice node is the preferred node is when the task is part of a workload that spans multiple NUMA nodes. Signed-off-by: Rik van Riel <riel@redhat.com> Tested-by: Vinod Chegu <chegu_vinod@hp.com> Acked-by: Mel Gorman <mgorman@suse.de> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1397235629-16328-4-git-send-email-riel@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions