Re: [PATCH 3/3] mm: optimize free_area_empty() check using per-migratetype counts

[Barry Song <baohua@kernel.org>]

On Tue, Mar 3, 2026 at 4:32 PM Hongru Zhang <zhanghongru06@gmail.com> wrote:
>
> > >
> > > From: Hongru Zhang <zhanghongru@xiaomi.com>
> > >
> > > Use per-migratetype counts instead of list_empty() helps reduce a
> > > few cpu instructions.
> > >
> > > Signed-off-by: Hongru Zhang <zhanghongru@xiaomi.com>
> > > ---
> > >  mm/internal.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/mm/internal.h b/mm/internal.h
> > > index 1561fc2ff5b8..7759f8fdf445 100644
> > > --- a/mm/internal.h
> > > +++ b/mm/internal.h
> > > @@ -954,7 +954,7 @@ int find_suitable_fallback(struct free_area *area, unsigned int order,
> > >
> > >  static inline bool free_area_empty(struct free_area *area, int migratetype)
> > >  {
> > > -       return list_empty(&area->free_list[migratetype]);
> > > +       return !READ_ONCE(area->mt_nr_free[migratetype]);
> >
> > I'm not quite sure about this. Since the counter is written and read more
> > frequently, cache coherence traffic may actually be higher than for the list
> > head.
> >
> > I'd prefer to drop this unless there is real data showing it performs better.
>
> Under the model described in email [1], with this patch (3/3), memory allocation
> performance is 0.36% better than without it.

I'm fine with the data, though my actual suggestion was to place each
mt_free_area in a separate cacheline to avoid false sharing. That one
could be separated if you see an obvious performance improvement.

For this patchset, I feel the main issue is convincing people of the value
of increasing counters in the alloc/free hotpath. As Johannes commented [1],
the new counters should provide more use cases than pagetypeinfo, or as Zi
Yan commented [2], clearly demonstrate the value that userspace derives from
pagetypeinfo.

Right now, pagetypeinfo is considered a debug interface, so its implementation
is quite poor.

[1] https://lore.kernel.org/all/20251128130823.GA222920@cmpxchg.org/
[2] https://lore.kernel.org/all/760FBDE3-2724-44A6-A874-BD87F0191C57@nvidia.com/

>
> Detailed data:
> - https://gist.github.com/zhr250/4439523b7ca3c18f4a2d2c97b24c4965
>
> Reference:
> [1] https://lore.kernel.org/linux-mm/20260303080423.472534-1-zhanghongru@xiaomi.com/

Thanks
Barry