The patch titled
Subject: arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
has been added to the -mm tree. Its filename is
arm-arm64-introduce-config_have_memblock_pfn_valid.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/arm-arm64-introduce-config_have_memblock_pfn_valid.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/arm-arm64-introduce-config_have_memblock_pfn_valid.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jia He <jia.he@xxxxxxxxxxxxxxxx>
Subject: arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
Patch series "optimize memblock_next_valid_pfn and early_pfn_valid on arm
and arm64", v10.
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") optimized the loop in memmap_init_zone(). But it causes
possible panic bug. So Daniel Vacek reverted it later.
But as suggested by Daniel Vacek, it is fine to using memblock to skip
gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
More from what Daniel said:
"On arm and arm64, memblock is used by default. But generic version of
pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
not always return the next valid one but skips more resulting in some
valid frames to be skipped (as if they were invalid). And that's why
kernel was eventually crashing on some !arm machines."
About the performance consideration:
As said by James in b92df1de5,
"I have tested this patch on a virtual model of a Samurai CPU with a
sparse memory map. The kernel boot time drops from 109 to 62 seconds."
Thus it would be better if we remain memblock_next_valid_pfn on arm/arm64.
Besides we can remain memblock_next_valid_pfn, there is still some room
for improvement. After this set, I can see the time overhead of
memmap_init is reduced from 27956us to 13537us in my armv8a server(QDF2400
with 96G memory, pagesize 64k). I believe arm server will benefit more if
memory is larger than TBs
Patch 1 introduces new config to make codes more generic
Patch 2 remains the memblock_next_valid_pfn on arm and arm64,this patch is
originated from b92df1de5
Patch 3 optimizes the memblock_next_valid_pfn()
Patch 4~6 optimizes the early_pfn_valid()
This patch (of 6):
Make CONFIG_HAVE_MEMBLOCK_PFN_VALID a new config option so it can move
memblock_next_valid_pfn to generic code file. All the latter
optimizations are based on this config.
The memblock initialization time on arm/arm64 can benefit from this.
Link: http://lkml.kernel.org/r/1530867675-9018-2-git-send-email-hejianet@xxxxxxxxx
Signed-off-by: Jia He <jia.he@xxxxxxxxxxxxxxxx>
Reviewed-by: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Cc: Russell King <linux@xxxxxxxxxxxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
Cc: Will Deacon <will.deacon@xxxxxxx>
Cc: Mark Rutland <mark.rutland@xxxxxxx>
Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Wei Yang <richard.weiyang@xxxxxxxxx>
Cc: Kees Cook <keescook@xxxxxxxxxxxx>
Cc: Laura Abbott <labbott@xxxxxxxxxx>
Cc: Vladimir Murzin <vladimir.murzin@xxxxxxx>
Cc: Philip Derrin <philip@cog.systems>
Cc: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
Cc: James Morse <james.morse@xxxxxxx>
Cc: Steve Capper <steve.capper@xxxxxxx>
Cc: Gioh Kim <gi-oh.kim@xxxxxxxxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Cc: Mel Gorman <mgorman@xxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Kemi Wang <kemi.wang@xxxxxxxxx>
Cc: Petr Tesarik <ptesarik@xxxxxxxx>
Cc: YASUAKI ISHIMATSU <yasu.isimatu@xxxxxxxxx>
Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
Cc: Nikolay Borisov <nborisov@xxxxxxxx>
Cc: Daniel Jordan <daniel.m.jordan@xxxxxxxxxx>
Cc: Daniel Vacek <neelx@xxxxxxxxxx>
Cc: Eugeniu Rosca <erosca@xxxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
arch/arm/Kconfig | 4 ++++
arch/arm64/Kconfig | 4 ++++
mm/Kconfig | 3 +++
3 files changed, 11 insertions(+)
diff -puN arch/arm64/Kconfig~arm-arm64-introduce-config_have_memblock_pfn_valid arch/arm64/Kconfig
--- a/arch/arm64/Kconfig~arm-arm64-introduce-config_have_memblock_pfn_valid
+++ a/arch/arm64/Kconfig
@@ -778,6 +778,10 @@ config ARCH_SELECT_MEMORY_MODEL
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
+config HAVE_MEMBLOCK_PFN_VALID
+ def_bool y
+ depends on HAVE_ARCH_PFN_VALID
+
config HW_PERF_EVENTS
def_bool y
depends on ARM_PMU
diff -puN arch/arm/Kconfig~arm-arm64-introduce-config_have_memblock_pfn_valid arch/arm/Kconfig
--- a/arch/arm/Kconfig~arm-arm64-introduce-config_have_memblock_pfn_valid
+++ a/arch/arm/Kconfig
@@ -1642,6 +1642,10 @@ config ARCH_SELECT_MEMORY_MODEL
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
+config HAVE_MEMBLOCK_PFN_VALID
+ def_bool y
+ depends on HAVE_ARCH_PFN_VALID
+
config HAVE_GENERIC_GUP
def_bool y
depends on ARM_LPAE
diff -puN mm/Kconfig~arm-arm64-introduce-config_have_memblock_pfn_valid mm/Kconfig
--- a/mm/Kconfig~arm-arm64-introduce-config_have_memblock_pfn_valid
+++ a/mm/Kconfig
@@ -137,6 +137,9 @@ config HAVE_MEMBLOCK_NODE_MAP
config HAVE_MEMBLOCK_PHYS_MAP
bool
+config HAVE_MEMBLOCK_PFN_VALID
+ bool
+
config HAVE_GENERIC_GUP
bool
_
Patches currently in -mm which might be from jia.he@xxxxxxxxxxxxxxxx are
arm-arm64-introduce-config_have_memblock_pfn_valid.patch
mm-page_alloc-remain-memblock_next_valid_pfn-on-arm-arm64.patch
mm-page_alloc-reduce-unnecessary-binary-search-in-memblock_next_valid_pfn.patch
mm-memblock-introduce-memblock_search_pfn_regions.patch
mm-memblock-introduce-pfn_valid_region.patch
mm-page_alloc-reduce-unnecessary-binary-search-in-early_pfn_valid.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
