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]> 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. -- Oscar Salvador SUSE Labs
