Re: [PATCH 2/2] mm/migrate: exclude hugetlb folios from MTHP_STAT_NR_ANON accounting

[Nico Pache]

On Thu, Jul 2, 2026 at 9:10 PM Baolin Wang
<baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 7/3/26 1:25 AM, Nico Pache wrote:
> > __folio_migrate_mapping() increments MTHP_STAT_NR_ANON for the
> > destination folio when `folio_test_anon(folio) && folio_test_large(folio)`
> > is true. However, hugetlb folios satisfy both conditions despite having a
> > completely separate accounting system; they use hugetlb_add_anon_rmap()
> > which does not touch mTHP stats, and their free path also bypasses the
> > mTHP decrement in __free_pages_prepare().
> >
> > This causes MTHP_STAT_NR_ANON to be incremented on each hugetlb
> > migration without a corresponding decrement, permanently inflating the
> > nr_anon counter.
> >
> > Add a !folio_test_hugetlb() check to both places in
> > __folio_migrate_mapping() so that only actual mTHP folios are counted.
> >
> > Fixes: 5d65c8d758f2 ("mm: count the number of anonymous THPs per size")
> > Co-developed-by: David Hildenbrand <david@xxxxxxxxxx>
> > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
> > Signed-off-by: Nico Pache <npache@xxxxxxxxxx>
> > ---
> >   mm/migrate.c | 6 ++++--
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index d9b23909d716..9fd50ea25d2d 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -590,7 +590,8 @@ static int __folio_migrate_mapping(struct address_space *mapping,
> >               /* No turning back from here */
> >               newfolio->index = folio->index;
> >               newfolio->mapping = folio->mapping;
> > -             if (folio_test_anon(folio) && folio_test_large(folio))
> > +             if (folio_test_anon(folio) && folio_test_large(folio) &&
> > +                 !folio_test_hugetlb(folio))
> >                       mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, 1);
>
> Yes, anonymous hugetlb mappings can reach here, so this check looks
> reasonable to me.
>
> >               if (folio_test_swapbacked(folio))
> >                       __folio_set_swapbacked(newfolio);
> > @@ -623,7 +624,8 @@ static int __folio_migrate_mapping(struct address_space *mapping,
> >        */
> >       newfolio->index = folio->index;
> >       newfolio->mapping = folio->mapping;
> > -     if (folio_test_anon(folio) && folio_test_large(folio))
> > +     if (folio_test_anon(folio) && folio_test_large(folio) &&
> > +         !folio_test_hugetlb(folio))
>
> If the hugetlb folio has a non-NULL mapping (i.e., it's a shared
> mapping), we should migrate it via
> hugetlbfs_migrate_folio()->migrate_huge_page_move_mapping(). In other
> words, shared hugetlb mappings should not reach this path, so this
> hugetlb check can be dropped. Or am I missing something?

I double checked (and others seem to have confirmed), you are correct;
these hugetlb pages shouldn't be reachable here.

Ill drop this hunk and retest :)

Thank you,
-- Nico

>
> >               mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, 1);
> >       folio_ref_add(newfolio, nr); /* add cache reference */
> >       if (folio_test_swapbacked(folio))
>