All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Muchun Song <songmuchun@bytedance.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Oscar Salvador <osalvador@suse.de>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	Christophe Leroy <chleroy@kernel.org>,
	aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/5] mm/sparse-vmemmap: Pass @pgmap argument to memory deactivation paths
Date: Thu, 23 Apr 2026 10:14:16 +0800	[thread overview]
Message-ID: <3745D308-DF29-477C-A25F-CDA63400D5ED@linux.dev> (raw)
In-Reply-To: <fc80afb9-6e97-481f-8136-d684ff3690a7@kernel.org>



> On Apr 23, 2026, at 02:50, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> On 4/22/26 10:14, Muchun Song wrote:
>> Currently, the memory hot-remove call chain -- arch_remove_memory(),
>> __remove_pages(), sparse_remove_section() and section_deactivate() --
>> does not carry the struct dev_pagemap pointer. This prevents the lower
>> levels from knowing whether the section was originally populated with
>> vmemmap optimizations (e.g., DAX with vmemmap optimization enabled).
>> 
>> Without this information, we cannot call vmemmap_can_optimize() to
>> determine if the vmemmap pages were optimized. As a result, the vmemmap
>> page accounting during teardown will mistakenly assume a non-optimized
>> allocation, leading to incorrect memmap statistics.
>> 
>> To lay the groundwork for fixing the vmemmap page accounting, we need
>> to pass the @pgmap pointer down to the deactivation location. Plumb the
>> @pgmap argument through the APIs of arch_remove_memory(), __remove_pages()
>> and sparse_remove_section(), mirroring the corresponding *_activate()
>> paths.
>> 
>> Signed-off-by: Muchun Song <songmuchun@bytedance.com>
>> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>> Reviewed-by: Oscar Salvador <osalvador@suse.de>
> 
> 
> [...]
> 
>> static void depopulate_section_memmap(unsigned long pfn, unsigned long nr_pages,
>> - 		struct vmem_altmap *altmap)
>> + 		struct vmem_altmap *altmap, struct dev_pagemap *pgmap)
>> {
>> 	unsigned long start = (unsigned long) pfn_to_page(pfn);
>> 	unsigned long end = start + nr_pages * sizeof(struct page);
>> @@ -746,7 +746,7 @@ static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages)
>>  * usage map, but still need to free the vmemmap range.
>>  */
>> static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
>> - 		struct vmem_altmap *altmap)
>> + 		struct vmem_altmap *altmap, struct dev_pagemap *pgmap)
>> {
>> 	struct mem_section *ms = __pfn_to_section(pfn);
>> 	bool section_is_early = early_section(ms);
>> @@ -784,7 +784,7 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
>>  * section_activate() and pfn_valid() .
>>  */
>> 	if (!section_is_early)
>> - 		depopulate_section_memmap(pfn, nr_pages, altmap);
>> + 		depopulate_section_memmap(pfn, nr_pages, altmap, pgmap);
>> 	else if (memmap)
>> 		free_map_bootmem(memmap);
>> 
>> @@ -828,7 +828,7 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn,
>> 
>> 	memmap = populate_section_memmap(pfn, nr_pages, nid, altmap, pgmap);
>> 	if (!memmap) {
>> - 		section_deactivate(pfn, nr_pages, altmap);
>> + 		section_deactivate(pfn, nr_pages, altmap, pgmap);
>> 		return ERR_PTR(-ENOMEM);
>> 	}
>> 
>> @@ -889,13 +889,13 @@ int __meminit sparse_add_section(int nid, unsigned long start_pfn,
>> }
>> 
>> void sparse_remove_section(unsigned long pfn, unsigned long nr_pages,
>> -    			   struct vmem_altmap *altmap)
>> +    			   struct vmem_altmap *altmap, struct dev_pagemap *pgmap)
> 
> While at it, could switch to two-tab indent here as well.

OK.

> 
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks.

Muchun.

> 
> -- 
> Cheers,
> 
> David




  reply	other threads:[~2026-04-23  2:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-22  8:14 [PATCH v4 0/5] mm: Fix vmemmap optimization accounting and initialization Muchun Song
2026-04-22  8:14 ` [PATCH v4 1/5] mm/sparse-vmemmap: Fix vmemmap accounting underflow Muchun Song
2026-04-22 18:47   ` David Hildenbrand (Arm)
2026-04-22  8:14 ` [PATCH v4 2/5] mm/sparse-vmemmap: Pass @pgmap argument to memory deactivation paths Muchun Song
2026-04-22 18:50   ` David Hildenbrand (Arm)
2026-04-23  2:14     ` Muchun Song [this message]
2026-04-22  8:14 ` [PATCH v4 3/5] mm/sparse-vmemmap: Fix DAX vmemmap accounting with optimization Muchun Song
2026-04-22 18:53   ` David Hildenbrand (Arm)
2026-04-23  2:17     ` Muchun Song
2026-04-22  8:14 ` [PATCH v4 4/5] mm/mm_init: Fix pageblock migratetype for ZONE_DEVICE compound pages Muchun Song
2026-04-22 19:03   ` David Hildenbrand (Arm)
2026-04-23  3:11     ` Muchun Song
2026-04-22  8:14 ` [PATCH v4 5/5] mm/mm_init: Fix uninitialized struct pages for ZONE_DEVICE Muchun Song
2026-04-22 19:12   ` 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=3745D308-DF29-477C-A25F-CDA63400D5ED@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=david@kernel.org \
    --cc=joao.m.martins@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ljs@kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mhocko@suse.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=osalvador@suse.de \
    --cc=rppt@kernel.org \
    --cc=songmuchun@bytedance.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /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.