From: Mike Rapoport <rppt@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Yuan Liu <yuan1.liu@intel.com>,
Oscar Salvador <osalvador@suse.de>,
Wei Yang <richard.weiyang@gmail.com>,
linux-mm@kvack.org, Nanhai Zou <nanhai.zou@intel.com>,
Chen Zhang <zhangchen.kidd@jd.com>,
Jason Zeng <jason.zeng@intel.com>, Chen Yu <yu.c.chen@intel.com>,
Pan Deng <pan.deng@intel.com>, Tianyou Li <tianyou.li@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 2/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range
Date: Tue, 15 Sep 2026 21:58:09 +0300 [thread overview]
Message-ID: <aqmVQeETYhbsl79A@kernel.org> (raw)
In-Reply-To: <209de483-a9a5-4d98-bda4-7998e8fdc7da@kernel.org>
On Tue, Sep 15, 2026 at 05:20:07PM +0200, David Hildenbrand (Arm) wrote:
> On 9/15/26 08:03, Mike Rapoport wrote:
> > Hi,
> >
> > On Mon, Sep 14, 2026 at 03:29:29AM -0400, Yuan Liu wrote:
> >> When move_pfn_range_to_zone() or remove_pfn_range_from_zone() updates a
> >> zone, set_zone_contiguous() rescans the entire zone pageblock-by-pageblock
> >> to rebuild zone->contiguous. For large zones this is a significant cost
> >> during memory hotplug and hot-unplug.
> >>
> >> diff --git a/mm/mm_init.c b/mm/mm_init.c
> >> index 1533aebafb68..d40a8ff23370 100644
> >> --- a/mm/mm_init.c
> >> +++ b/mm/mm_init.c
> >> @@ -817,22 +817,39 @@ void __meminit init_deferred_page(unsigned long pfn, int nid)
> >> * zone/node above the hole except for the trailing pages in the last
> >> * section that will be appended to the zone/node below.
> >> */
> >> -static void __init init_unavailable_range(unsigned long spfn,
> >> - unsigned long epfn,
> >> - int zone, int node)
> >> +static unsigned long __init init_unavailable_range(unsigned long spfn,
> >> + unsigned long epfn,
> >> + int zone, int node)
> >> {
> >> + unsigned long next_chunk_pfn __maybe_unused = spfn;
> >> unsigned long pfn;
> >> - u64 pgcnt = 0;
> >> + u64 online_pgcnt = 0, pgcnt = 0;
> >> + bool is_online = true;
> >>
> >> for_each_valid_pfn(pfn, spfn, epfn) {
> >> __init_single_page(pfn_to_page(pfn), pfn, zone, node);
> >> __SetPageReserved(pfn_to_page(pfn));
> >> pgcnt++;
> >> +
> >> + /*
> >> + * With vmemmap, at this stage all pages in an early section
> >> + * have a valid memmap and are marked as online. However, only
> >> + * subsections in the subsection map are actually online.
> >> + */
> >
> > I'm having trouble parsing this comment. Shouldn't is say that some
> > subsections in a section can be offline because of holes?
>
>
> Maybe extending that a bit we could do
>
> "With CONFIG_SPARSEMEM_VMEMMAP, early sections have a valid memmap for all PFNs
> and the sections are marked online. However, we might have offline subsections
> in such early sections, indicated by the subsection map. While we must
> initialize the entire valid memmap, account only the online pages according to
> the subsection map as online (see pfn_to_online_page())."
init_unavailable_range() already has large comment on top, adding something
like that there makes perfect sense to me :)
How about a bit different version:
* The function counts pages that should be added to
* zone->pages_with_online_memmap.
* With CONFIG_SPARSEMEM_VMEMMAP there could be offline subsections even though
* the entire memory map is valid and all the early sections are online.
* Count only pages in online subsections (see pfn_to_online_page()).
> --
> Cheers,
>
> David
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-09-15 18:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 7:29 [PATCH v9 0/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range Yuan Liu
2026-09-14 7:29 ` [PATCH v9 1/2] mm/memory_hotplug: make shrink_zone_span() more robust Yuan Liu
2026-09-14 7:29 ` [PATCH v9 2/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range Yuan Liu
2026-09-15 6:03 ` Mike Rapoport
2026-09-15 10:40 ` Liu, Yuan1
2026-09-15 12:52 ` Mike Rapoport
2026-09-15 15:20 ` David Hildenbrand (Arm)
2026-09-15 18:58 ` Mike Rapoport [this message]
2026-09-18 2:08 ` Liu, Yuan1
2026-09-18 12:15 ` David Hildenbrand (Arm)
2026-09-14 10:45 ` [PATCH v9 0/2] " 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=aqmVQeETYhbsl79A@kernel.org \
--to=rppt@kernel.org \
--cc=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=tianyou.li@intel.com \
--cc=yu.c.chen@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.