From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F4D5238D52 for ; Fri, 12 Jun 2026 02:44:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781232250; cv=none; b=HTcJIsp7ghgrf1Yfj1cukK59csEfxCx9dQSFlfZ29Zb+vIM/A2m4rdpchOUYDwvLa4Jz/QeXSU/5SXr+0N2A08TLPLbElwiyqDUofG8/+lnL6ulsImdr6tTS4HMBQ1xXXo/g/vGbsnqLVWb1I4sBXfhXiBil73JAbgWPPEj1WzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781232250; c=relaxed/simple; bh=LgrqMbASWspgUH3jiD0QGJltyJvKGNto7FQm96rnh5o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E2jy6rburctAt4omxfGQFi/9PQD219DW+C7MY2PgtCwA2e0JTy+VHuQq/UGjavg29Hw241LlmLS7kRsScDCYICUAbyb/rHWaYb2g4mkURzRlG3iQ9HVzF5NEyp3S9NTudwFMUbz4AoMYxItQQ9AqglH+uWmL5vUH7ngz2QbPVnc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=awiPF+fO; arc=none smtp.client-ip=209.85.218.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="awiPF+fO" Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-bf0170c80f7so87410966b.3 for ; Thu, 11 Jun 2026 19:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781232247; x=1781837047; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=FKA0Ut3WlW3n5UQsohG5A8jL7XKlqbjEiKYDixP3dak=; b=awiPF+fO46OjSpUH73k62Pkmh25yM0q6lV/4jrTGqs00xZxDhtEZJ3fSujGgXUwqJV Wyv1dD9qY/QQQWJTQusX8CSc1dNEdYXn7w6VfgpB7lmHEof6mG9iEMxTdQYxS+gnBR6B kPEOxtEdsWwD5ggYYQj+rqws1y9zP504Mtbny8mviNOotHxqYMO5AnA1IagSsvKUUwhm Fvo2fay5vc1y6YH5kE6wLXHfaaEQCoTX/VteD2c9InjnCBOq3xe6pn/KmzsSBrVk5ZnY O0ph0HDAPsh8rqqzNr7vevggGE/bNnfsRKHyrx3Tzz+mPFQkE5FeXtEjl3xnOx8SR91Z gPOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781232247; x=1781837047; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FKA0Ut3WlW3n5UQsohG5A8jL7XKlqbjEiKYDixP3dak=; b=iwS7TkQitiu+AQtvSWxwxwQ1jSyuMG8OQz1Oz6aIxjQiAeZpH/dDDA/souqKfrAhJU 8oJoFXP+a4Th4l06sQptyDJl9yA4EW7KiEVeZ1NZqzDZtLS/j5itdjlOh8xpqDkQLLTd Ge5r/rh6+1rxQdNtyJbJHfhcxgxb/rK5KPVYbvbMgNJe0X3/dpE7EZEGghwoS5Pa3Z8f YJE29NACt1LakESiK3/D2OdUc2WzM5CMXWy+CUfeVMhkQ78rMzmobrOCDuk97o/Gqlfi dLl2UsEmhkKNi14xdV5vQlon0fpqXo1BBbtTcZO9ChP1vm4NiBVDdrOyW15+c298Saqu JdSA== X-Forwarded-Encrypted: i=1; AFNElJ/iP9O45l084hxMqX1T3uKACH/gNgiaBUpPT/5nH8Mzo91MfitET/mHor8bT4LKbp0AFIIhvnKeJFV4PhU=@vger.kernel.org X-Gm-Message-State: AOJu0YzH1i5NYFbk6Wp+tDZbLv0UxSdm2C6VvbsobGhsLF5TITAnPm7P W8sJ+sp+CA5EX6DwY3S5SVB92xCQi9aj+y4VqejEVchAjRA6LZ5YZCuZ X-Gm-Gg: Acq92OFOv3S8cLUIZrhU6UpHbH7m7gbFQU1HQ6YeZsQWvI+Qt2SGOX7PdMUqaYckOuq 3EXaT1kk60xIahU4NklIf2CwOV1tGZD/02Z1dQjLU3oTc8cVkqjMQM+VV8Yg/CBZy1dJFyJS1Rq 2gyV0V4srynquvdibfcZWlToxjnYOnYbKKE5DWGgaTlL6i7ZAVyGeScdqs75QQ+OE4jmooLXxWE cGpoCikA3JKDlfnXeHekiM30zZtBPWM8gZ2913DtEJug4fzNGaJWiSxq5qjJFWSE9Q6YfOzy0cf 1x6aY3CB4lFQlyaf5XwlUXRBTAoW0OuEDJ1cR20cw7zL8pGbprBBtvs5XyL8P3/pH9fLtAKH1Pn cwB8UdGf7cTsWV3Y02HNFlfCYQxWE1SFixjeGLMAinlqzPDsmKYklVBt+cWvgr5uCfWdbcwaPdc E6HmiuoRfxoqk8WXxDGbV3DA== X-Received: by 2002:a17:907:3e0b:b0:bec:427b:f5b0 with SMTP id a640c23a62f3a-bfe27b26ad5mr21063066b.14.1781232246550; Thu, 11 Jun 2026 19:44:06 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bfdb4420854sm46252066b.7.2026.06.11.19.44.04 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Jun 2026 19:44:05 -0700 (PDT) Date: Fri, 12 Jun 2026 02:44:04 +0000 From: Wei Yang To: "Liu, Yuan1" Cc: Wei Yang , David Hildenbrand , Oscar Salvador , Mike Rapoport , "linux-mm@kvack.org" , "Hu, Yong" , "Zou, Nanhai" , Tim Chen , "Zhuo, Qiuxu" , "Chen, Yu C" , "Deng, Pan" , "Li, Tianyou" , Chen Zhang , "Zeng, Jason" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v5 1/5] mm: move mirrored memory overlap checking to the outer loop Message-ID: <20260612024404.suzszzpzj3x7e7cu@master> Reply-To: Wei Yang References: <20260520093457.3719960-1-yuan1.liu@intel.com> <20260520093457.3719960-2-yuan1.liu@intel.com> <20260521033303.7jg66h4sxwi4l3cm@master> <20260525083554.6x6l5y46icekegzg@master> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) On Tue, Jun 02, 2026 at 07:55:11AM +0000, Liu, Yuan1 wrote: >> -----Original Message----- >> From: Wei Yang >> Sent: Monday, May 25, 2026 4:36 PM >> To: Liu, Yuan1 >> Cc: Wei Yang ; David Hildenbrand >> ; Oscar Salvador ; Mike Rapoport >> ; linux-mm@kvack.org; Hu, Yong ; Zou, >> Nanhai ; Tim Chen ; >> Zhuo, Qiuxu ; Chen, Yu C ; >> Deng, Pan ; Li, Tianyou ; Chen >> Zhang ; Zeng, Jason ; linux- >> kernel@vger.kernel.org >> Subject: Re: [PATCH v5 1/5] mm: move mirrored memory overlap checking to >> the outer loop >> >> On Fri, May 22, 2026 at 07:43:38AM +0000, Liu, Yuan1 wrote: >> >> Subject: Re: [PATCH v5 1/5] mm: move mirrored memory overlap checking >> to >> >> the outer loop >> >> >> >> On Wed, May 20, 2026 at 05:34:53AM -0400, Yuan Liu wrote: >> >> >Move the overlap memmap initialization check from memmap_init_range() >> >> >to memmap_init(), and replace the per-PFN check with a memblock-based >> >> >check. >> >> >> >> The description is a little simple. >> >> >> >> Even I know the purpose, I feel confused at the first glance. >> > >> >Thanks for the review. >> >I will try to rephrase it and provide a clearer description in the next >> version. >> > >> >> > >> >> >Reviewed-by: Wei Yang >> >> >Reviewed-by: Jason Zeng >> >> >Signed-off-by: Yuan Liu >> >> >--- >> >> > mm/mm_init.c | 29 +++++------------------------ >> >> > 1 file changed, 5 insertions(+), 24 deletions(-) >> >> > >> >> >diff --git a/mm/mm_init.c b/mm/mm_init.c >> >> >index f9f8e1af921c..24e103a402b0 100644 >> >> >--- a/mm/mm_init.c >> >> >+++ b/mm/mm_init.c >> >> >@@ -783,28 +783,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 >> >> >@@ -891,8 +869,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; >> >> >@@ -956,6 +932,7 @@ static void __init memmap_init(void) >> >> > int i, j, zone_id = 0, nid; >> >> > >> >> > for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) >> >> { >> >> >+ struct memblock_region *r = &memblock.memory.regions[i]; >> >> > struct pglist_data *node = NODE_DATA(nid); >> >> > >> >> > for (j = 0; j < MAX_NR_ZONES; j++) { >> >> >@@ -964,6 +941,10 @@ static void __init memmap_init(void) >> >> > if (!populated_zone(zone)) >> >> > continue; >> >> > >> >> >+ if (mirrored_kernelcore && j == ZONE_MOVABLE && >> >> >+ memblock_is_mirror(r)) >> >> >+ continue; >> >> >+ >> >> >> >> So you have figured out the memory layout of mirror memory? >> >> >> >> Would you mind elaborate? >> > >> >I have a Xeon server, collected mirror memory layout information as below >> by using follow changes: >> > >> >int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t >> size) >> > { >> >- if (!mirrored_kernelcore) >> >+ int ret; >> >+ phys_addr_t end = base + size - 1; >> >+ >> >+ pr_info("memblock_mark_mirror: base=%pa, size=%pa, >> mirrored_kernelcore=%d\n", >> >+ &base, &size, mirrored_kernelcore); >> >+ >> >+ if (!mirrored_kernelcore) { >> >+ pr_info("memblock_mark_mirror: mirrored_kernelcore not >> enabled, skipping\n"); >> > return 0; >> >+ } >> > >> > system_has_some_mirror = true; >> > >> >- return memblock_setclr_flag(&memblock.memory, base, size, 1, >> MEMBLOCK_MIRROR); >> >+ ret = memblock_setclr_flag(&memblock.memory, base, size, 1, >> MEMBLOCK_MIRROR); >> >+ pr_info("memblock_mark_mirror: marked [%pa-%pa] as MIRROR, >> ret=%d\n", >> >+ &base, &end, ret); >> >+ return ret; >> > } >> > >> >Here is the detailed layout information: >> > >> >> Thanks for the detailed output. >> >> After some investigation, I got two things to discuss here: >> >> * current mirror memory would disable memmap defer init >> * confirm the mirror memory layout and may simplify handling >> >> Before discussion, let me mark the key point in the output below. >> >> >Case 1: efibootmgr -m t -M 0 >> >Enable mirror memory below 4GB, and no mirror memory above 4G >> > >> >=== zoneinfo summary === >> >node zone start_pfn end_pfn start_addr end_addr >> >------ ---------- ------------ ------------ ------------------ ---------- >> --- >> >0 DMA 0x1 0xfff 0x1000 0xffffff >> >0 DMA32 0x1000 0xfffff 0x1000000 0xffffffff >> >0 Normal 0x100000 0x7fbffff 0x100000000 0x7fbfffffff >> >0 Movable 0x140000 0x7fbffff 0x140000000 0x7fbfffffff >> >> (1) Normal and Movable zone end with the same address, so overlapped. >> >> >1 Normal 0x7fc0000 0xff7ffff 0x7fc0000000 >> 0xff7fffffff >> >1 Movable 0x8000000 0xff7ffff 0x8000000000 >> 0xff7fffffff >> >> The same as (1). >> >> > >> >node start end size flags mirror pfn_range >> >---- -------------------- -------------------- ------------ ------------ --- -------- ------------------ >> >0 0x0000000000001000 0x000000000009dfff 0x000000000009d000 0x2 yes 0x1-0x9e >> >0 0x000000000009f000 0x000000000009ffff 0x0000000000001000 0x2 yes 0x9f-0xa0 >> >0 0x0000000000100000 0x0000000066416fff 0x0000000066317000 0x2 yes 0x100-0x66417 >> >0 0x00000000777ff000 0x00000000777fffff 0x0000000000001000 0x2 yes 0x777ff-0x77800 >> >0 0x0000000100000000 0x000000013fffffff 0x0000000040000000 0x2 yes 0x100000-0x140000 >> >> (2) You mentioned no mirror memory above 4G. If my understanding is >> correct, 4G's >> address is 0x100000000. So why this range is marked mirror? Is there some >> limitation for this? > >Hi Wei > >efibootmgr enables mirror memory below 4 GB through the -m (--mirror-below-4G) >option, and configures the percentage of memory to be mirrored above 4 GB through >the -M (--mirror-above-4G) option. > The efibootmgr command used here is: efibootmgr -m t -M 0 This means we expect it configure 0% memory to be mirrored above 4G. But we see the range [0x100000000, 0x13ffffff] is mirrored, which is above 4G. Also for the range in node 1, we have mirrored memory. So I am afraid the behavior is not what it literally means. Or I missed something? While more critical thing to confirm is ... >My understanding is that the layout of mirrored memory is determined by the BIOS. ... after the BIOS configuration, kernel would only see contiguous mirrored memory for each NUMA node, right? So that we could handle mirrored memory correctly. BTW, I mentioned two issues in last reply: * error on node span calculation * defer_init misbehavior with mirrored memory Have you checked about it? Is my finding reasonable? -- Wei Yang Help you, Help me