summaryrefslogtreecommitdiffstats
path: root/net/sunrpc/xprtsock.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2011-03-11 10:33:31 +0100
committerTejun Heo <tj@kernel.org>2011-03-12 11:41:10 +0100
commit56396e6823fe9b42fe9cf9403d6ed67756255f70 (patch)
treefcdab8e467b74217e76aa5047e2fa7d5b1ea71b4 /net/sunrpc/xprtsock.c
parentca764aaf025d2c83054191895b366fa81a9ccf48 (diff)
downloadlinux-56396e6823fe9b42fe9cf9403d6ed67756255f70.tar.gz
linux-56396e6823fe9b42fe9cf9403d6ed67756255f70.tar.bz2
linux-56396e6823fe9b42fe9cf9403d6ed67756255f70.zip
x86-64, NUMA: Don't call numa_set_distanc() for all possible node combinations during emulation
The distance transforming in numa_emulation() used to call numa_set_distance() for all MAX_NUMNODES * MAX_NUMNODES node combinations regardless of which are enabled. As numa_set_distance() ignores all out-of-bound distance settings, this doesn't cause any problem other than looping unnecessarily many times during boot. However, as MAX_NUMNODES * MAX_NUMNODES can be pretty high, update the code such that it iterates through only the enabled combinations. Yinghai Lu identified the issue and provided an initial patch to address the issue; however, the patch was incorrect in that it didn't build emulated distance table when there's no physical distance table and unnecessarily complex. http://thread.gmane.org/gmane.linux.kernel/1107986/focus=1107988 Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Yinghai Lu <yinghai@kernel.org>
Diffstat (limited to 'net/sunrpc/xprtsock.c')
0 files changed, 0 insertions, 0 deletions