Linux-mm Archive on 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>,
	Chen Zhang <zhangchen.kidd@jd.com>,
	"Zeng, Jason" <jason.zeng@intel.com>,
	"Chen, Yu C" <yu.c.chen@intel.com>,
	"Deng, Pan" <pan.deng@intel.com>,
	"Li, Tianyou" <tianyou.li@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 2/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range
Date: Thu, 20 Aug 2026 19:46:17 +0200	[thread overview]
Message-ID: <bf298ebe-55bd-4f42-9339-9567eadaa514@kernel.org> (raw)
In-Reply-To: <MW4PR11MB69369259EB8B2FDF237B863AA3A42@MW4PR11MB6936.namprd11.prod.outlook.com>

>>> +			online_pgcnt++;
>>
>> Can we avoid these helpers?
>>
>> 		const unsigned long subsection = pfn & PAGE_SUBSECTION_MASK;
>>
>> 		/* We can have section-sized online holes with VMEMMAP. */
>> 		if (IS_ENMABLED(CONFIG_SPARSEMEM_VMEMMAP) &&
>> 		    subsection != last_subsection) {
>> 			is_online = pfn_to_online_page(pfn);
>> 			last_subsection = subsection;
>> 		}
>> 		if (is_online)
>> 			online_pgcnt++;
> 
> I think there may be an issue here: PAGE_SUBSECTION_MASK is not
> defined when CONFIG_FLATMEM is enabled, which would result in a
> build failure.

Ah, yeah.

> 
>> An alternative is an inner loop that just walks in SUBSECTION chunks until
>> epfn.
>> That would probably be even cleaner and faster.
>>
>> I remember !vmemmap always only has early sections when they are actually
>> online. We could extent the comment to clarify that.
> 
> Hi David
> 
> What about the following approach? It removes the helper and changes
> the per-PFN online check to a per-chunk check.
> 
> +       u64 pgcnt = 0, online_pgcnt = 0;
> +#ifdef CONFIG_SPARSEMEM_VMEMMAP
> +       const unsigned long chunk = PAGES_PER_SUBSECTION;
> +#else
> +       const unsigned long chunk = epfn - spfn;
> +#endif
> 
> -       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, subsection-sized holes can exist, and PFNs within
> +        * these holes can fail pfn_to_online_page(). Without VMEMMAP, we
> +        * always only have early sections when they are actually online.
> +        */
> +       for (pfn = spfn; pfn < epfn; pfn += chunk) {
> +               const unsigned long chunk_epfn = min(pfn + chunk, epfn);
> +               const bool is_online = !IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP) ||
> +                                      pfn_to_online_page(pfn);
> +               unsigned long p;
> +
> +               for_each_valid_pfn(p, pfn, chunk_epfn) {
> +                       __init_single_page(pfn_to_page(p), p, zone, node);
> +                       __SetPageReserved(pfn_to_page(p));
> +                       if (is_online)
> +                               online_pgcnt++;
> +                       pgcnt++;
> +               }

I'd keep the for_each_valid_pfn() the outer loop.

-- 
Cheers,

David


  reply	other threads:[~2026-08-20 17:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18  8:57 [PATCH v7 0/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range Yuan Liu
2026-08-18  8:57 ` [PATCH v7 1/2] mm/memory_hotplug: make shrink_zone_span() more robust Yuan Liu
2026-08-20 12:52   ` Liu, Yuan1
2026-08-21  3:14   ` Wei Yang
2026-08-18  8:57 ` [PATCH v7 2/2] mm/memory_hotplug: optimize zone contiguous check when changing pfn range Yuan Liu
2026-08-19 14:56   ` Mike Rapoport
2026-08-19 15:43     ` David Hildenbrand (Arm)
2026-08-19 15:53   ` David Hildenbrand (Arm)
2026-08-20 13:21     ` Liu, Yuan1
2026-08-20 17:46       ` David Hildenbrand (Arm) [this message]
2026-08-21  3:17         ` 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=bf298ebe-55bd-4f42-9339-9567eadaa514@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox