Re: [tip:x86/mm] x86/mm/numa: Fix 32-bit kernel NUMA boot
On 12/20/2013 12:44 AM, Yinghai Lu wrote:
On Thu, Dec 19, 2013 at 7:42 AM, tip-bot for Lans Zhang
wrote:
Commit-ID: f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Gitweb: http://git.kernel.org/tip/f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Author: Lans Zhang
AuthorDate: Fri, 6 Dec 2013 12:18:30 +0800
Committer: Ingo Molnar
CommitDate: Thu, 19 Dec 2013 13:58:36 +0100
x86/mm/numa: Fix 32-bit kernel NUMA boot
When booting a 32-bit x86 kernel on a NUMA machine, node data
cannot be allocated from local node if the account of memory for
node 0 covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from
other nodes if the memory of local node is still not mapped. The
expected result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhang
Cc:
Cc: Yinghai Lu
Link:
http://lkml.kernel.org/r/1386303510-18574-1-git-send-email-jia.zh...@windriver.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/numa.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err("Cannot find %zu bytes in node %d\n",
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
Can you just use memblock_alloc_try_nid instead memblock_alloc_nid?
But memblock_alloc_base() inside memblock_alloc_try_nid() may cause kernel panic
if __memblock_alloc_base() inside it fails. In current stage, it is allowed if
node data fails to be allocated.
Thanks,
lz
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm/numa: Fix 32-bit kernel NUMA boot
Commit-ID: f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Gitweb: http://git.kernel.org/tip/f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Author: Lans Zhang
AuthorDate: Fri, 6 Dec 2013 12:18:30 +0800
Committer: Ingo Molnar
CommitDate: Thu, 19 Dec 2013 13:58:36 +0100
x86/mm/numa: Fix 32-bit kernel NUMA boot
When booting a 32-bit x86 kernel on a NUMA machine, node data
cannot be allocated from local node if the account of memory for
node 0 covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from
other nodes if the memory of local node is still not mapped. The
expected result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhang
Cc:
Cc: Yinghai Lu
Link:
http://lkml.kernel.org/r/1386303510-18574-1-git-send-email-jia.zh...@windriver.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/numa.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err("Cannot find %zu bytes in node %d\n",
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/mm] x86/mm/numa: Fix 32-bit kernel NUMA boot
Commit-ID: f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Gitweb: http://git.kernel.org/tip/f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Author: Lans Zhang jia.zh...@windriver.com
AuthorDate: Fri, 6 Dec 2013 12:18:30 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 19 Dec 2013 13:58:36 +0100
x86/mm/numa: Fix 32-bit kernel NUMA boot
When booting a 32-bit x86 kernel on a NUMA machine, node data
cannot be allocated from local node if the account of memory for
node 0 covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from
other nodes if the memory of local node is still not mapped. The
expected result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhang jia.zh...@windriver.com
Cc: a...@firstfloor.org
Cc: Yinghai Lu ying...@kernel.org
Link:
http://lkml.kernel.org/r/1386303510-18574-1-git-send-email-jia.zh...@windriver.com
Signed-off-by: Ingo Molnar mi...@kernel.org
---
arch/x86/mm/numa.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err(Cannot find %zu bytes in node %d\n,
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err(Cannot find %zu bytes in node %d\n,
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/mm] x86/mm/numa: Fix 32-bit kernel NUMA boot
On 12/20/2013 12:44 AM, Yinghai Lu wrote:
On Thu, Dec 19, 2013 at 7:42 AM, tip-bot for Lans Zhang
tip...@zytor.com wrote:
Commit-ID: f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Gitweb: http://git.kernel.org/tip/f3d815cb854b2f6262ade56a4d91a1ed3f1e50c4
Author: Lans Zhangjia.zh...@windriver.com
AuthorDate: Fri, 6 Dec 2013 12:18:30 +0800
Committer: Ingo Molnarmi...@kernel.org
CommitDate: Thu, 19 Dec 2013 13:58:36 +0100
x86/mm/numa: Fix 32-bit kernel NUMA boot
When booting a 32-bit x86 kernel on a NUMA machine, node data
cannot be allocated from local node if the account of memory for
node 0 covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from
other nodes if the memory of local node is still not mapped. The
expected result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhangjia.zh...@windriver.com
Cc:a...@firstfloor.org
Cc: Yinghai Luying...@kernel.org
Link:
http://lkml.kernel.org/r/1386303510-18574-1-git-send-email-jia.zh...@windriver.com
Signed-off-by: Ingo Molnarmi...@kernel.org
---
arch/x86/mm/numa.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err(Cannot find %zu bytes in node %d\n,
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err(Cannot find %zu bytes in node %d\n,
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
Can you just use memblock_alloc_try_nid instead memblock_alloc_nid?
But memblock_alloc_base() inside memblock_alloc_try_nid() may cause kernel panic
if __memblock_alloc_base() inside it fails. In current stage, it is allowed if
node data fails to be allocated.
Thanks,
lz
Thanks
Yinghai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/mm/numa: fix becoming single node on numa machine with 32-bit kernel.
On numa machine, if a 32-bit kernel runs over it, node data cannot
be allocated from local node if the account of memory for node 0
covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from other
nodes if the memory of local node is still not mapped. The expected
result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhang
---
arch/x86/mm/numa.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err("Cannot find %zu bytes in node %d\n",
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err("Cannot find %zu bytes in node %d\n",
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
--
1.7.8.110.g4cb5d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/mm/numa: fix becoming single node on numa machine with 32-bit kernel.
On numa machine, if a 32-bit kernel runs over it, node data cannot
be allocated from local node if the account of memory for node 0
covers the low memory space entirely:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] Cannot find 4096 bytes in node 1
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
To fix this issue, node data is allowed to be allocated from other
nodes if the memory of local node is still not mapped. The expected
result looks like this:
[0.00] Initmem setup node 0 [mem 0x-0x83fff]
[0.00] NODE_DATA [mem 0x367ed000-0x367edfff]
[0.00] Initmem setup node 1 [mem 0x84000-0xf]
[0.00] NODE_DATA [mem 0x367ec000-0x367ecfff]
[0.00] NODE_DATA(1) on node 0
[0.00] 64664MB HIGHMEM available.
[0.00] 871MB LOWMEM available.
Signed-off-by: Lans Zhang jia.zh...@windriver.com
---
arch/x86/mm/numa.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 24aec58..c85da7b 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -211,9 +211,13 @@ static void __init setup_node_data(int nid, u64 start, u64
end)
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
- pr_err(Cannot find %zu bytes in node %d\n,
- nd_size, nid);
- return;
+ nd_pa = __memblock_alloc_base(nd_size, SMP_CACHE_BYTES,
+ MEMBLOCK_ALLOC_ACCESSIBLE);
+ if (!nd_pa) {
+ pr_err(Cannot find %zu bytes in node %d\n,
+ nd_size, nid);
+ return;
+ }
}
nd = __va(nd_pa);
--
1.7.8.110.g4cb5d
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cleanups] x86_64: Use __BOOT_DS instead_of __KERNEL_DS for safety
Commit-ID: 2dead15fb8f6522b96c913603b5ad0b5c7d01f49 Gitweb: http://git.kernel.org/tip/2dead15fb8f6522b96c913603b5ad0b5c7d01f49 Author: Lans Zhang AuthorDate: Fri, 1 Mar 2013 09:20:39 +0800 Committer: H. Peter Anvin CommitDate: Fri, 1 Mar 2013 10:18:33 -0800 x86_64: Use __BOOT_DS instead_of __KERNEL_DS for safety In startup_32, the running code still uses the initial GDT located in setup. Thus, __BOOT_DS is preferred. Currently __KERNEL_DS is lucky to equal to __BOOT_DS, but this is not always a safe way. Signed-off-by: Lans Zhang Link: http://lkml.kernel.org/r/51300267.6000...@gmail.com Signed-off-by: H. Peter Anvin --- arch/x86/boot/compressed/head_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S index c1d383d..16f24e6 100644 --- a/arch/x86/boot/compressed/head_64.S +++ b/arch/x86/boot/compressed/head_64.S @@ -52,7 +52,7 @@ ENTRY(startup_32) jnz 1f cli - movl$(__KERNEL_DS), %eax + movl$(__BOOT_DS), %eax movl%eax, %ds movl%eax, %es movl%eax, %ss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cleanups] x86_64: Use __BOOT_DS instead_of __KERNEL_DS for safety
Commit-ID: 2dead15fb8f6522b96c913603b5ad0b5c7d01f49 Gitweb: http://git.kernel.org/tip/2dead15fb8f6522b96c913603b5ad0b5c7d01f49 Author: Lans Zhang lans.zhang2...@gmail.com AuthorDate: Fri, 1 Mar 2013 09:20:39 +0800 Committer: H. Peter Anvin h...@linux.intel.com CommitDate: Fri, 1 Mar 2013 10:18:33 -0800 x86_64: Use __BOOT_DS instead_of __KERNEL_DS for safety In startup_32, the running code still uses the initial GDT located in setup. Thus, __BOOT_DS is preferred. Currently __KERNEL_DS is lucky to equal to __BOOT_DS, but this is not always a safe way. Signed-off-by: Lans Zhang lans.zhang2...@gmail.com Link: http://lkml.kernel.org/r/51300267.6000...@gmail.com Signed-off-by: H. Peter Anvin h...@linux.intel.com --- arch/x86/boot/compressed/head_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S index c1d383d..16f24e6 100644 --- a/arch/x86/boot/compressed/head_64.S +++ b/arch/x86/boot/compressed/head_64.S @@ -52,7 +52,7 @@ ENTRY(startup_32) jnz 1f cli - movl$(__KERNEL_DS), %eax + movl$(__BOOT_DS), %eax movl%eax, %ds movl%eax, %es movl%eax, %ss -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
