From: Jinyang He <hejinyang@loongson.cn>
To: Huang Pei <huangpei@loongson.cn>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
ambrosehua@gmail.com
Cc: Bibo Mao <maobibo@loongson.cn>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mips@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org, Jiaxun Yang <jiaxun.yang@flygoat.com>,
Paul Burton <paulburton@kernel.org>,
Li Xuefeng <lixuefeng@loongson.cn>,
Yang Tiezhu <yangtiezhu@loongson.cn>,
Gao Juxin <gaojuxin@loongson.cn>,
Fuxin Zhang <zhangfx@lemote.com>, Huacai Chen <chenhc@lemote.com>
Subject: Re: [PATCH] MIPS: loongson64: alloc pglist_data at run time
Date: Mon, 1 Mar 2021 16:42:45 +0800 [thread overview]
Message-ID: <a80f5a8f-972a-08f6-f8e3-032ca5ef321a@loongson.cn> (raw)
In-Reply-To: <20210227062957.269156-1-huangpei@loongson.cn>
On 02/27/2021 02:29 PM, Huang Pei wrote:
> It can make some metadata of MM, like pglist_data and zone
> NUMA-aware
>
> Signed-off-by: Huang Pei <huangpei@loongson.cn>
> ---
> arch/mips/loongson64/numa.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
> index cf9459f79f9b..5912b2e7b10c 100644
> --- a/arch/mips/loongson64/numa.c
> +++ b/arch/mips/loongson64/numa.c
> @@ -26,7 +26,6 @@
> #include <asm/wbflush.h>
> #include <boot_param.h>
>
> -static struct pglist_data prealloc__node_data[MAX_NUMNODES];
> unsigned char __node_distances[MAX_NUMNODES][MAX_NUMNODES];
> EXPORT_SYMBOL(__node_distances);
> struct pglist_data *__node_data[MAX_NUMNODES];
> @@ -151,8 +150,12 @@ static void __init szmem(unsigned int node)
>
> static void __init node_mem_init(unsigned int node)
> {
> + struct pglist_data *nd;
> unsigned long node_addrspace_offset;
> unsigned long start_pfn, end_pfn;
> + unsigned long nd_pa;
> + int tnid;
> + const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
>
> node_addrspace_offset = nid_to_addrbase(node);
> pr_info("Node%d's addrspace_offset is 0x%lx\n",
> @@ -162,8 +165,16 @@ static void __init node_mem_init(unsigned int node)
> pr_info("Node%d: start_pfn=0x%lx, end_pfn=0x%lx\n",
> node, start_pfn, end_pfn);
>
> - __node_data[node] = prealloc__node_data + node;
> -
> + nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, node);
[...]
Hi, all,
Few related to this patch. About memblock, I have a question.
In my own understanding, 3 stages at previous part of arch_mem_init().
stage1: Add memory to memblock.memory at plat_mem_setup().
stage2: parse_early_param() parses parameter about memroy, such as "mem"
"memmap".
check_kernel_sections_mem() checks whether the current
memblock.memory contains the kernel.
At this stage, user can defined memblock.memory by themselves.
Also it is the final stage of determining memblock.memory.
stage3: others. use memblock.memory and add them to memblock.reserve.
Calling to memblock_alloc*() should be after the reserve kernel(), see:
memblock_set_current_limit(PFN_PHYS(max_low_pfn))
(
Here few about this patch: It works no problem, memblock_dump shows:
[ 0.000000] memory.cnt = 0x2
[ 0.000000] memory[0x0] [0x0000000000200000-0x000000000effffff],
0x000000000ee00000 bytes on node 0 flags: 0x0
[ 0.000000] memory[0x1] [0x0000000090200000-0x000000025fffffff],
0x00000001cfe00000 bytes on node 0 flags: 0x0
[ 0.000000] reserved.cnt = 0x3
[ 0.000000] reserved[0x0] [0x0000000000200000-0x0000000001ed7fff],
0x0000000001cd8000 bytes flags: 0x0
[ 0.000000] reserved[0x1] [0x00000000fe000000-0x00000000ffffffff],
0x0000000002000000 bytes flags: 0x0
--->>> [ 0.000000] reserved[0x2]
[0x000000025fffd6c0-0x000000025fffffff], 0x0000000000002940 bytes flags:
0x0 <<<---
memblock.bottom_up is not enabled here, and it is not destroy kernel,
although looks strange.
)
Morever, about "mem" parameter.
When parsing the mem parameter for the first time, all memblock.memory
is removed.
For NUMA, memblock.memory contain important node information. These
information are
imported at plat_mem_setup(). Without these node information, the NUMA
platform
may not be able to use memory correctly.
The mem parameter is rarely used, but it has meaning. For example,
kdump. I have
done some fixes before, but it looks fool.
Huacai suggested me that use pa_to_nid().
memblock_add(start, size) -> memblock_add_node(start, size,
pa_to_nid(start))
I think this is a good way. Does anyone have other suggestions?
At last, should the NUMA platform reserve the kernel area after parse
"mem" rather than before it?
Thanks,
Jinyang
next prev parent reply other threads:[~2021-03-01 8:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-27 6:29 Huang Pei
2021-02-28 8:43 ` Sergei Shtylyov
2021-03-01 8:42 ` Jinyang He [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-02-21 3:05 Huang Pei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a80f5a8f-972a-08f6-f8e3-032ca5ef321a@loongson.cn \
--to=hejinyang@loongson.cn \
--cc=akpm@linux-foundation.org \
--cc=ambrosehua@gmail.com \
--cc=chenhc@lemote.com \
--cc=gaojuxin@loongson.cn \
--cc=huangpei@loongson.cn \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lixuefeng@loongson.cn \
--cc=maobibo@loongson.cn \
--cc=paulburton@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=yangtiezhu@loongson.cn \
--cc=zhangfx@lemote.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox