From: Zhen Lei <thunder.leizhen@huawei.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm <linux-mm@kvack.org>
Cc: Zefan Li <lizefan@huawei.com>, Xinwei Hu <huxinwei@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>,
Zhen Lei <thunder.leizhen@huawei.com>
Subject: [PATCH 0/2] to support memblock near alloc and memoryless on arm64
Date: Tue, 25 Oct 2016 10:59:16 +0800 [thread overview]
Message-ID: <1477364358-10620-1-git-send-email-thunder.leizhen@huawei.com> (raw)
If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
actually exist. The percpu variable areas and numa control blocks of that
memoryless numa nodes need to be allocated from the nearest available
node to improve performance.
In the beginning, I added a new function:
phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size, phys_addr_t align, int nid);
But it can not replace memblock_virt_alloc_try_nid, because the latter can specify a min_addr,
it usually be assigned as __pa(MAX_DMA_ADDRESS), to prevent memory be allocated from DMA area.
It's bad to add another function, because the code will be duplicated in these two functions.
So I make memblock_alloc_near_nid to be called in the subfunctions of memblock_alloc_try_nid
and memblock_virt_alloc_try_nid. Add a macro node_distance_ready to distinguish different
situations:
1) By default, the value of node_distance_ready is zero, memblock_*_try_nid work as normal as before.
2) ARCH platforms set the value of node_distance_ready to be true when numa node distances are ready, (please refer patch 2)
memblock_*_try_nid allocate memory from the nearest node relative to the specified node.
Zhen Lei (2):
mm/memblock: prepare a capability to support memblock near alloc
arm64/numa: support HAVE_MEMORYLESS_NODES
arch/arm64/Kconfig | 4 +++
arch/arm64/include/asm/numa.h | 3 ++
arch/arm64/mm/numa.c | 6 +++-
mm/memblock.c | 76 ++++++++++++++++++++++++++++++++++++-------
4 files changed, 77 insertions(+), 12 deletions(-)
--
2.5.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2016-10-25 3:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-25 2:59 Zhen Lei [this message]
2016-10-25 2:59 ` [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc Zhen Lei
2016-10-25 13:23 ` Michal Hocko
2016-10-26 3:10 ` Leizhen (ThunderTown)
2016-10-26 9:31 ` Michal Hocko
2016-10-27 2:41 ` Leizhen (ThunderTown)
2016-10-27 7:22 ` Michal Hocko
2016-10-27 8:23 ` Leizhen (ThunderTown)
2016-10-25 2:59 ` [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES Zhen Lei
2016-10-26 18:36 ` Will Deacon
2016-10-27 3:54 ` Leizhen (ThunderTown)
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=1477364358-10620-1-git-send-email-thunder.leizhen@huawei.com \
--to=thunder.leizhen@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=guohanjun@huawei.com \
--cc=huxinwei@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).