From: Hanjun Guo <guohanjun@huawei.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, "Jia He" <hejianet@gmail.com>, Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org> Cc: <linux-arm-kernel@lists.infradead.org>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, Hanjun Guo <guohanjun@huawei.com> Subject: [PATCH v12 0/2] introduce memblock_next_valid_pfn() (again) for arm64 Date: Tue, 23 Jul 2019 13:51:11 +0800 [thread overview] Message-ID: <1563861073-47071-1-git-send-email-guohanjun@huawei.com> (raw) Here is new version of "[PATCH v11 0/3] remain and optimize memblock_next_valid_pfn on arm and arm64" from Jia He, which is suggested by Ard to respin this patch set [1]. In the new version, I squashed patch 1/3 and patch 2/3 in v11 into one patch, fixed a bug for possible out of bound accessing the regions, and just introduce memblock_next_valid_pfn() for arm64 only as I don't have a arm32 platform to test. Ard asked to "with the new data points added for documentation, and crystal clear about how the meaning of PFN validity differs between ARM and other architectures, and why the assumptions that the optimization is based on are guaranteed to hold", to be honest, I didn't see PFN validity differs between ARM and x86 architecture, but there is a bug in commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") which has a possible out of bound accessing the regions as well, so not sure that is the root cause. Testing on a HiSilicon ARM64 server (a 4 sockets system), I can get pretty much speedup for bootmem_init() at boot: with 384G memory, before: 13310ms after: 1415ms with 1T memory, before: 20s after: 2s [1]: https://lkml.org/lkml/2019/6/10/412 Jia He (2): mm: page_alloc: introduce memblock_next_valid_pfn() (again) for arm64 mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn arch/arm64/Kconfig | 1 + include/linux/mmzone.h | 9 +++++++ mm/Kconfig | 3 +++ mm/memblock.c | 56 ++++++++++++++++++++++++++++++++++++++++++ mm/page_alloc.c | 4 ++- 5 files changed, 72 insertions(+), 1 deletion(-) -- 2.19.1
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <guohanjun@huawei.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, "Jia He" <hejianet@gmail.com>, Mike Rapoport <rppt@linux.ibm.com>, Will Deacon <will@kernel.org> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Hanjun Guo <guohanjun@huawei.com> Subject: [PATCH v12 0/2] introduce memblock_next_valid_pfn() (again) for arm64 Date: Tue, 23 Jul 2019 13:51:11 +0800 [thread overview] Message-ID: <1563861073-47071-1-git-send-email-guohanjun@huawei.com> (raw) Here is new version of "[PATCH v11 0/3] remain and optimize memblock_next_valid_pfn on arm and arm64" from Jia He, which is suggested by Ard to respin this patch set [1]. In the new version, I squashed patch 1/3 and patch 2/3 in v11 into one patch, fixed a bug for possible out of bound accessing the regions, and just introduce memblock_next_valid_pfn() for arm64 only as I don't have a arm32 platform to test. Ard asked to "with the new data points added for documentation, and crystal clear about how the meaning of PFN validity differs between ARM and other architectures, and why the assumptions that the optimization is based on are guaranteed to hold", to be honest, I didn't see PFN validity differs between ARM and x86 architecture, but there is a bug in commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible") which has a possible out of bound accessing the regions as well, so not sure that is the root cause. Testing on a HiSilicon ARM64 server (a 4 sockets system), I can get pretty much speedup for bootmem_init() at boot: with 384G memory, before: 13310ms after: 1415ms with 1T memory, before: 20s after: 2s [1]: https://lkml.org/lkml/2019/6/10/412 Jia He (2): mm: page_alloc: introduce memblock_next_valid_pfn() (again) for arm64 mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn arch/arm64/Kconfig | 1 + include/linux/mmzone.h | 9 +++++++ mm/Kconfig | 3 +++ mm/memblock.c | 56 ++++++++++++++++++++++++++++++++++++++++++ mm/page_alloc.c | 4 ++- 5 files changed, 72 insertions(+), 1 deletion(-) -- 2.19.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2019-07-23 5:53 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-23 5:51 Hanjun Guo [this message] 2019-07-23 5:51 ` [PATCH v12 0/2] introduce memblock_next_valid_pfn() (again) for arm64 Hanjun Guo 2019-07-23 5:51 ` [PATCH v12 1/2] mm: page_alloc: " Hanjun Guo 2019-07-23 5:51 ` Hanjun Guo 2019-07-23 8:30 ` Mike Rapoport 2019-07-23 8:30 ` Mike Rapoport 2019-07-24 8:29 ` Hanjun Guo 2019-07-24 8:29 ` Hanjun Guo 2019-08-01 8:06 ` Ard Biesheuvel 2019-08-01 8:06 ` Ard Biesheuvel 2019-08-01 8:06 ` Ard Biesheuvel 2019-07-23 5:51 ` [PATCH v12 2/2] mm: page_alloc: reduce unnecessary binary search in memblock_next_valid_pfn Hanjun Guo 2019-07-23 5:51 ` Hanjun Guo 2019-07-23 8:33 ` Mike Rapoport 2019-07-23 8:33 ` Mike Rapoport 2019-07-24 8:33 ` Hanjun Guo 2019-07-24 8:33 ` Hanjun Guo
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=1563861073-47071-1-git-send-email-guohanjun@huawei.com \ --to=guohanjun@huawei.com \ --cc=akpm@linux-foundation.org \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=hejianet@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=rppt@linux.ibm.com \ --cc=will@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.