[PATCH v6 4/7] mm/sparse-vmemmap: Fix DAX vmemmap accounting with optimization

[Muchun Song]

> On Apr 25, 2026, at 14:47, David Hildenbrand (Arm) <david at kernel.org> wrote:
> 
> On 4/25/26 08:20, Muchun Song wrote:
>> 
>> 
>>>> On Apr 25, 2026, at 13:48, David Hildenbrand (Arm) <david at kernel.org> wrote:
>>> 
>>> 
>>>> 
>>>> 
>>>> Hi David,
>>>> 
>>>> Sorry, I missed the 1GB hugepage scenario earlier. Given that sparse_add_section()
>>>> operates on a scale between PAGES_PER_SUBSECTION and PAGES_PER_SECTION, the pfn and
>>>> nr_pages parameters wouldn't be aligned with the hugepage size (pages_per_compound),
>>>> but rather with the PAGES_PER_SECTION boundary. Do you think this explanation makes
>>>> it clearer? In the interest of code clarity, do you think the modification below
>>>> makes it easier to follow?
>>>> 
>>>> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
>>>> index 2e642c5ff3f2..ce675c5fb94d 100644
>>>> --- a/mm/sparse-vmemmap.c
>>>> +++ b/mm/sparse-vmemmap.c
>>>> @@ -658,15 +658,18 @@ static int __meminit section_nr_vmemmap_pages(unsigned long pfn, unsigned long n
>>>>       const unsigned int order = pgmap ? pgmap->vmemmap_shift : 0;
>>>>       const unsigned long pages_per_compound = 1UL << order;
>>>> 
>>>> -       VM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages,
>>>> -                                   min(pages_per_compound, PAGES_PER_SECTION)));
>>>> +       VM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, PAGES_PER_SUBSECTION));
>>> 
>>> That here makes sense. We can only add/remove in multiples of PAGES_PER_SECTION.
>>> I think what we are saying is that we want that check in addition to the
>>> existing min() check.
>> 
>> Right.
>> 
>>> 
>>>>       VM_WARN_ON_ONCE(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)
>>>> +       if (order < PFN_SECTION_SHIFT) {
>>>> +               VM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, pages_per_compound));
>>>>               return VMEMMAP_RESERVE_NR * nr_pages / pages_per_compound;
>>> 
>>> That makes sense as well, within a section, we expect that we always add/remove
>>> entire "compound"-managed chunks.
>>> 
>>>> +       }
>>>> +
>>>> +       VM_WARN_ON_ONCE(!IS_ALIGNED(pfn | nr_pages, PAGES_PER_SECTION));
>>> 
>>> And this is then for the case where a 1G page spans multiple sections, where we
>>> expect to add/remove an entire section.
>>> 
>>> So here, indeed the "min" makes sense. I guess we also assume:
>>> 
>>>   VM_WARN_ON_ONCE(nr_pages > PAGES_PER_SECTION);
>> 
>> Yes. But this one we do not need to explicit it to
>> assert it since at the front of this function we have
>> 
>> VM_WARN_ON_ONCE(pfn_to_section_nr(pfn) != pfn_to_section_nr(pfn + nr_pages - 1));
> 
> Ah, yes. The alignment checks + VM_WARN_ON_ONCE(nr_pages > PAGES_PER_SECTION);
> however imply that.
> 
> So you could simplify by using that check instead of the pfn_to_section_nr() check.
> 
> But it's still early here ... so whatever you prefer :)

Thanks for the suggestion. I think your approach is also
good — at least it looks shorter and cleaner. I'll switch to
using VM_WARN_ON_ONCE(nr_pages > PAGES_PER_SECTION) instead.

Thanks.

> 
> --
> Cheers,
> 
> David