2014-01-07 06:11:06

by Stephen Rothwell

[permalink] [raw]
Subject: linux-next: manual merge of the akpm-current tree with the tip tree

Hi Andrew,

Today's linux-next merge of the akpm-current tree got a conflict in
arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
pg_data_t's memory from other node") from the akpm-current tree.

These appear to be two very similar solutions, I fixed it up (see below -
I (arbitrarily) chose to keep the actual allocation from the tip tree, but
the messages from the akpm-current tree) and can carry the fix as
necessary (no action is required).

--
Cheers,
Stephen Rothwell [email protected]

diff --cc arch/x86/mm/numa.c
index c85da7bb6b60,f26b16f0d3e0..000000000000
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@@ -211,11 -211,12 +211,12 @@@ static void __init setup_node_data(int
*/
nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
+ pr_warn("Cannot find %zu bytes in node %d, so try other nodes",
+ nd_size, nid);
- nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES,
- MAX_NUMNODES);
+ 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);
+ pr_err("Cannot find %zu bytes in any node\n", nd_size);
return;
}
}


Attachments:
(No filename) (1.31 kB)
(No filename) (836.00 B)
Download all attachments

2014-01-07 06:32:08

by Tang Chen

[permalink] [raw]
Subject: Re: linux-next: manual merge of the akpm-current tree with the tip tree

On 01/07/2014 02:00 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> Today's linux-next merge of the akpm-current tree got a conflict in
> arch/x86/mm/numa.c between commit f3d815cb854b ("x86/mm/numa: Fix 32-bit
> kernel NUMA boot") from the tip tree and commit 1459be89954e ("x86: get
> pg_data_t's memory from other node") from the akpm-current tree.
>
> These appear to be two very similar solutions, I fixed it up (see below -
> I (arbitrarily) chose to keep the actual allocation from the tip tree, but
> the messages from the akpm-current tree) and can carry the fix as
> necessary (no action is required).
>

memblock_alloc_nid() and __memblock_alloc_base() will call
memblock_alloc_base_nid() in the end. So I think it is OK to me.

I will do some tests when they are merged.

Thanks.