mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: rppt@kernel.org, akpm@linux-foundation.org, izumi.taku@jp.fujitsu.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	david@kernel.org, yuan1.liu@intel.com,
	Wei Yang <richard.weiyang@gmail.com>
Subject: [RFC Patch 2/3] mm/mm_init: remove overlap_memmap_init() as no overlapped zone
Date: Tue, 23 Jun 2026 09:23:50 +0000	[thread overview]
Message-ID: <20260623092351.13031-3-richard.weiyang@gmail.com> (raw)
In-Reply-To: <20260623092351.13031-1-richard.weiyang@gmail.com>

When commit 342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror
option") is introduced, it would have overlapped Zone Normal and Zone
Movable. And this original code would initialize overlapped range twice.

For example, if the memory layout is below:

  memory[0x0]     [0x0000000000001000-0x000000000009efff], 0x000000000009e000 bytes on node 0 flags: 0x2
  memory[0x1]     [0x0000000000100000-0x00000000bffdefff], 0x00000000bfedf000 bytes on node 0 flags: 0x2
  memory[0x2]     [0x0000000100000000-0x000000013fffffff], 0x0000000040000000 bytes on node 0 flags: 0x2
  memory[0x3]     [0x0000000140000000-0x00000001bfffffff], 0x0000000080000000 bytes on node 0 flags: 0x0

We would get Zone range with kernelcore=mirror set:

  Normal  [100000, 1c0000]
  Movable [140000, 1c0000]

According to original logic, during memmap_init() it calls
memmap_init_zone_range() with the same range from
for_each_mem_pfn_range() for each populated zone. And then clamp the
same memory range with specific zone boundary.

  memmap_init()
      for_each_mem_pfn_range(&start_pfn, &end_pfn)
          for: zone = ZONE_DMA, ZONE_DEVICE
              memmap_init_zone_range(zone, start_pfn, end_pfn)   <-- same range, but different zone
                  memmap_init_range()                            <-- clamped with zone range

For the last memblock region:

  [0x0000000140000000-0x00000001bfffffff]

It belongs to both Zone Normal and Zone Movable, which means the same range
would be initialized twice by memmap_init_range(), but with different
zone_id.

Original code is expected to skip overlapped range with
overlap_memmap_init(). But it only skip when (zone == ZONE_MOVABLE), which
in turn has no effect for this memory layout. So the last range is first
initialized to Zone Normal, then to Zone Movable which is what we
expect.

After previous cleanup, the overlapped zone is gone, so the
overlap_memmap_init() is not necessary anymore.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Yuan Liu <yuan1.liu@intel.com>
---
 mm/mm_init.c | 24 ------------------------
 1 file changed, 24 deletions(-)

diff --git a/mm/mm_init.c b/mm/mm_init.c
index b8ff4aff19c0..da0e65bf8d02 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -797,28 +797,6 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)
 	__init_deferred_page(pfn, nid);
 }
 
-/* If zone is ZONE_MOVABLE but memory is mirrored, it is an overlapped init */
-static bool __meminit
-overlap_memmap_init(unsigned long zone, unsigned long *pfn)
-{
-	static struct memblock_region *r __meminitdata;
-
-	if (mirrored_kernelcore && zone == ZONE_MOVABLE) {
-		if (!r || *pfn >= memblock_region_memory_end_pfn(r)) {
-			for_each_mem_region(r) {
-				if (*pfn < memblock_region_memory_end_pfn(r))
-					break;
-			}
-		}
-		if (*pfn >= memblock_region_memory_base_pfn(r) &&
-		    memblock_is_mirror(r)) {
-			*pfn = memblock_region_memory_end_pfn(r);
-			return true;
-		}
-	}
-	return false;
-}
-
 /*
  * Only struct pages that correspond to ranges defined by memblock.memory
  * are zeroed and initialized by going through __init_single_page() during
@@ -905,8 +883,6 @@ void __meminit memmap_init_range(unsigned long size, int nid, unsigned long zone
 		 * function.  They do not exist on hotplugged memory.
 		 */
 		if (context == MEMINIT_EARLY) {
-			if (overlap_memmap_init(zone, &pfn))
-				continue;
 			if (defer_init(nid, pfn, zone_end_pfn)) {
 				deferred_struct_pages = true;
 				break;
-- 
2.34.1


  parent reply	other threads:[~2026-06-23  9:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  9:23 [RFC Patch 0/3] mm/mm_init: fix and cleanup mirrored_kernelcore Wei Yang
2026-06-23  9:23 ` [RFC Patch 1/3] mm/mm_init: adjust overlapped zone for mirror memory too Wei Yang
2026-06-23  9:23 ` Wei Yang [this message]
2026-06-23  9:23 ` [RFC Patch 3/3] mm/mm_init: remove special handling absent pages for mirrored_kernelcore Wei Yang
2026-06-25  6:36 ` [RFC Patch 0/3] mm/mm_init: fix and cleanup mirrored_kernelcore David Hildenbrand (Arm)

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=20260623092351.13031-3-richard.weiyang@gmail.com \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    --cc=yuan1.liu@intel.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

all inboxes | Powered by JetHome®