On 4/5/26 14:51, Muchun Song wrote:
> When HVO is enabled for DAX, the vmemmap page accounting is wrong since
> it only accounts for non-HVO case.
>
> Fix the accounting by introducing section_vmemmap_pages() that returns
> the exact number of vmemmap pages needed for the given pfn range.
>
> Fixes: 15995a352474 ("mm: report per-page metadata information")
> Signed-off-by: Muchun Song <[email protected]>
> ---
> mm/sparse-vmemmap.c | 30 ++++++++++++++++++++++++++----
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> index 7aa9a97498eb..0ef96b1afbcc 100644
> --- a/mm/sparse-vmemmap.c
> +++ b/mm/sparse-vmemmap.c
> @@ -724,6 +724,27 @@ static int fill_subsection_map(unsigned long pfn,
> unsigned long nr_pages)
> return rc;
> }
>
> +static int __meminit section_vmemmap_pages(unsigned long pfn, unsigned long
> nr_pages,
> + struct vmem_altmap *altmap, struct
> dev_pagemap *pgmap)
> +{
> + unsigned int order = pgmap ? pgmap->vmemmap_shift : 0;
> + unsigned long pages_per_compound = 1L << order;
> +
> + VM_BUG_ON(!IS_ALIGNED(pfn | nr_pages, min(pages_per_compound,
> PAGES_PER_SECTION)));
> + VM_BUG_ON(pfn_to_section_nr(pfn) != pfn_to_section_nr(pfn + nr_pages -
> 1));
> +
> + if (!vmemmap_can_optimize(altmap, pgmap))
> + return DIV_ROUND_UP(nr_pages * sizeof(struct page), PAGE_SIZE);
> +
> + if (order < PFN_SECTION_SHIFT)
> + return VMEMMAP_RESERVE_NR * nr_pages / pages_per_compound;
> +
> + if (IS_ALIGNED(pfn, pages_per_compound))
> + return VMEMMAP_RESERVE_NR;
This makes me wonder whether that is really the right place to update
the counter. Can't we update the counter where we actually allocate/free
the pages, so we don't have to re-calculate that?
--
Cheers,
David
