Re: [PATCH v2 3/8] mm: move anon-exclusive batch helper to mm.h

[Dev Jain <dev.jain@arm.com>]

On 01/09/26 11:19 am, Barry Song wrote:
> On Tue, Sep 1, 2026 at 1:44 PM Dev Jain <dev.jain@arm.com> wrote:
>>
>> In preparation for optimizing large folio unmapping, we need to reuse
>> the page_anon_exclusive_batch helper in rmap.c and rmap.h and obey the
>> existing use in mprotect.c .
>>
>> Therefore, move it from mprotect.c to mm.h. Gate with CONFIG_MMU since
>> both rmap and mprotect users are built only for CONFIG_MMU.
>>
>> While at it, change start_idx and max_len to unsigned long type for
>> future proofing against THP support at >= PUD level. Also shorten
>> expected_anon_exclusive -> anon_exclusive.
>>
>> Signed-off-by: Dev Jain <dev.jain@arm.com>
>> ---
>>  include/linux/mm.h | 19 +++++++++++++++++++
>>  mm/mprotect.c      | 17 -----------------
>>  2 files changed, 19 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index dd09c438fa23e..63da8813bc5df 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -244,6 +244,25 @@ static inline unsigned long folio_page_idx(const struct folio *folio,
>>         return page - &folio->page;
>>  }
>>
>> +#ifdef CONFIG_MMU
>> +/*
>> + * Get max length of consecutive PTEs pointing to PageAnonExclusive() pages or
>> + * !PageAnonExclusive() pages, starting from start_idx. Caller must enforce
>> + * that the PTEs point to consecutive pages of the same anon large folio.
>> + */
>> +static __always_inline int page_anon_exclusive_batch(unsigned long start_idx,
>> +               unsigned long max_len, struct page *first_page, bool anon_exclusive)
>> +{
>> +       int idx;
>> +
>> +       for (idx = start_idx + 1; idx < start_idx + max_len; ++idx) {
>> +               if (anon_exclusive != PageAnonExclusive(first_page + idx))
>> +                       break;
>> +       }
>> +       return idx - start_idx;
>> +}
>> +#endif
>> +
> 
> Hi Dev,
> 
> I really don't want everything to become a top-level header
> file. If these are only mm-internal things, could we move them
> to mm/internal.h or another more appropriate header?

What do you suggest? I had it in mm/internal.h initially, but
because I had to use the helper this time in patch 4, I couldn't
do that. The helper will now be used by mprotect.c, rmap.c and
rmap.h.

I can keep it in rmap.h and make mprotect.c include rmap.h too.


> 
> Best Regards
> Barry