diff options
author | Ravikiran G Thirumalai <kiran@scalex86.org> | 2005-09-30 11:59:22 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-09-30 12:41:20 -0700 |
commit | 85cc5135ace4c8b75d7b4e1ea9fe15a7fcbd1516 (patch) | |
tree | 9b671671331c8da39dc2a9b75e3d34d79aeac86e /Makefile | |
parent | e6a045a5b89037ae87c8c1bc84403f1d498e52a1 (diff) | |
download | linux-85cc5135ace4c8b75d7b4e1ea9fe15a7fcbd1516.tar.gz linux-85cc5135ace4c8b75d7b4e1ea9fe15a7fcbd1516.tar.bz2 linux-85cc5135ace4c8b75d7b4e1ea9fe15a7fcbd1516.zip |
[PATCH] x86_64 early numa init fix
The tests Alok carried out on Petr's box confirmed that cpu_to_node[BP] is
not setup early enough by numa_init_array due to the x86_64 changes in
2.6.14-rc*, and unfortunately set wrongly by the work around code in
numa_init_array(). cpu_to_node[0] gets set with 1 early and later gets set
properly to 0 during identify_cpu() when all cpus are brought up, but
confusing the numa slab in the process.
Here is a quick fix for this. The right fix obviously is to have
cpu_to_node[bsp] setup early for numa_init_array(). The following patch
will fix the problem now, and the code can stay on even when
cpu_to_node{BP] gets fixed early correctly.
Thanks to Petr for access to his box.
Signed off by: Ravikiran Thirumalai <kiran@scalex86.org>
Signed-off-by: Alok N Kataria <alokk@calsoftinc.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions