All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Liu, Yuan1" <yuan1.liu@intel.com>,
	Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>,
	Wei Yang <richard.weiyang@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Zou, Nanhai" <nanhai.zou@intel.com>,
	"Deng, Pan" <pan.deng@intel.com>,
	"Li, Tianyou" <tianyou.li@intel.com>,
	Chen Zhang <zhangchen.kidd@jd.com>,
	"Zeng, Jason" <jason.zeng@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 1/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range
Date: Tue, 11 Aug 2026 14:23:18 +0200	[thread overview]
Message-ID: <01795519-54e8-4ed8-a94e-2b77780abc3a@kernel.org> (raw)
In-Reply-To: <f0593f56-870e-4e79-8552-1760fad255bc@kernel.org>

On 8/10/26 16:04, David Hildenbrand (Arm) wrote:
>>
>> Hi David
>>
>> My understanding is that init_unavailable_range() initializes all
>> PFNs that satisfy pfn_valid(), but not all of them satisfy
>> pfn_to_online_page(), since some PFNs belong to subsections that are
>> not online.
> 
> Thanks for reminding me. I think the right direction is to finally clean up the
> pfn_valid() handling.
> 
>>
>> You previously mentioned:
>>
>>   pfn_valid() says early sections always have a full memmap, so even invalid
>>   subsections have a memmap. pfn_to_online_page() says an invalid subsection
>>   cannot be online and its content must be stale. for_each_valid_pfn() follows
>>   pfn_valid() semantics, and we use it to initialize memmap that is not going
>>   to be online and account it as pages_with_online_memmap, which is wrong.
>>
>>   The cleanest approach is to avoid allocating memmap for subsections, which
>>   also removes the special early-section handling from pfn_valid() and
>>   for_each_valid_pfn().
>>
>> I also share the concerns raised by Sashiko in the analysis below [1]:
>>
>>   Scanners like isolate_migratepages_block() will then blindly iterate through
>>   the pageblock and access the completely uninitialized struct pages of the hole,
>>   leading to functional errors or kernel panics when reading these zero-filled
>>   structures via macros like PageHuge() or page_zone().
>>
>> That's why we went with the current approach in v6 instead of your
>> earlier suggestion. I'd really appreciate your guidance on which
>> direction you think would be more appropriate.
> Let me take a stab at just having pfn_valid() / for_each_valid_pfn() respecting
> the subsection map.

... and that turns complicated very quickly. The problem is that we have some users,
in particular the buddy, that just assumes that MAX_PAGE_ORDER regions are fully
accessible.

The fun begins once we have MAX_PAGE_ORDER span multiple subsections. So we'd actually
want to initialize the memmap.

The pfn_valid() vs. pfn_to_online_page() inconsistency is really nasty :(

I mean, in init_unavailable_range() we could actually figure out fairly easily
whether we are dealing with holes where pfn_to_online_page() would succeed.

diff --git a/mm/mm_init.c b/mm/mm_init.c
index e9c4204b73adb..54e71e17f2c3c 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -843,11 +843,13 @@ static void __init init_unavailable_range(unsigned long spfn,
                                          int zone, int node)
 {
        unsigned long pfn;
-       u64 pgcnt = 0;
+       u64 pgcnt = 0, online_pgcnt = 0;
 
        for_each_valid_pfn(pfn, spfn, epfn) {
                __init_single_page(pfn_to_page(pfn), pfn, zone, node);
                __SetPageReserved(pfn_to_page(pfn));
+               if (pfn_to_online_page(pfn))
+                       online_pgcnt++;
                pgcnt++;
        }

If it's a problem performance-wise, we can always try optimizing by skipping
checks within the same (sub)section.


-- 
Cheers,

David


  reply	other threads:[~2026-08-11 12:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-23  8:49 [PATCH v6 0/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range Yuan Liu
2026-07-23  8:49 ` [PATCH v6 1/2] " Yuan Liu
2026-08-05 11:53   ` David Hildenbrand (Arm)
2026-08-06  7:23     ` Liu, Yuan1
2026-08-06  8:45       ` David Hildenbrand (Arm)
2026-08-06  9:52         ` Liu, Yuan1
2026-08-07 11:29           ` David Hildenbrand (Arm)
2026-08-07 12:15             ` Liu, Yuan1
2026-08-09  3:12               ` Wei Yang
2026-08-10 14:04               ` David Hildenbrand (Arm)
2026-08-11 12:23                 ` David Hildenbrand (Arm) [this message]
2026-07-23  8:49 ` [PATCH v6 2/2] mm/memory_hotplug: improve shrink_zone_span() subsection boundary checks Yuan Liu
2026-07-25  2:49   ` Wei Yang
2026-07-27  9:49     ` Liu, Yuan1
2026-07-30  2:36       ` Wei Yang
2026-07-30  7:57         ` Liu, Yuan1
2026-08-01  0:59           ` Wei Yang
2026-08-05 11:02   ` David Hildenbrand (Arm)
2026-08-06  7:14     ` Liu, Yuan1
2026-08-07  3:22     ` Wei Yang
2026-08-07 11:25       ` David Hildenbrand (Arm)
2026-08-05  9:40 ` [PATCH v6 0/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range Liu, Yuan1

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=01795519-54e8-4ed8-a94e-2b77780abc3a@kernel.org \
    --to=david@kernel.org \
    --cc=jason.zeng@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nanhai.zou@intel.com \
    --cc=osalvador@suse.de \
    --cc=pan.deng@intel.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rppt@kernel.org \
    --cc=tianyou.li@intel.com \
    --cc=yuan1.liu@intel.com \
    --cc=zhangchen.kidd@jd.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 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.