> On Apr 21, 2026, at 11:55, Oscar Salvador <[email protected]> wrote:
>
> On Tue, Apr 21, 2026 at 10:20:42AM +0800, 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 <[email protected]>
>> Acked-by: Mike Rapoport (Microsoft) <[email protected]>
>
> Reviewed-by: Oscar Salvador <[email protected]>
Thanks.
>
> The change looks good to me, but I was wondering whether we should pass a
> mhp struct instead to low-level functions like arch_remove_memory and
> __remove_pages and have __remove_pages then pass the right stuff down
> the road.
> That way it would mimic more what we do in hot-add path.
Passing the pgmap parameter is a temporary fix, as I have another
patchset coming up to remove pgmap entirely [1].
[1]
https://lore.kernel.org/linux-mm/[email protected]/
Thanks,
Muchun.
>
>
> --
> Oscar Salvador
> SUSE Labs
