[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201213150942.20990-1-bhe@redhat.com>
Date: Sun, 13 Dec 2020 23:09:40 +0800
From: Baoquan He <bhe@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, gopakumarr@...are.com,
akpm@...ux-foundation.org, rppt@...nel.org,
natechancellor@...il.com, ndesaulniers@...gle.com,
clang-built-linux@...glegroups.com, rostedt@...dmis.org,
manir@...are.com, lauyiuch@...are.com, pjonasson@...are.com,
rajaramv@...are.com
Subject: [PATCH 0/2] Fix the incorrect memmap init defer handling
VMware reported the performance regression during memmap_init() invocation.
And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over
memblock regions rather that check each PFN") causing it.
After investigation, it's caused by incorrect memmap init defer handling
in memmap_init_zone() after commit 73a6e474cb376. The current
memmap_init_zone() only handle one memory region of one zone, while
memmap_init() iterates over all its memory regions and pass them one by
one into memmap_init_zone() to handle.
So in this patchset, patch 1/2 fixes the bug observed by VMware. Patch
2/2 clean up the inappropriate name of memmap_init(), memmap_init_zone()
accordingly.
VMware helped do the testing on their VMware ESI platform. This patchset
is based on 5.10.0-rc7+, master branch of Linus's tree.
Baoquan He (2):
mm: memmap defer init dosn't work as expected
mm: rename memmap_init() and memmap_init_zone()
arch/ia64/mm/init.c | 8 ++++----
include/linux/mm.h | 5 +++--
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 22 ++++++++++++----------
4 files changed, 20 insertions(+), 17 deletions(-)
--
2.17.2
Powered by blists - more mailing lists