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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4wCeLr6KOTU=Pc4ALeq5x-i0C7i6C3cSddexHw2ADSnng@mail.gmail.com>
Date: Sat, 29 Nov 2025 17:24:01 +0800
From: Barry Song <21cnbao@...il.com>
To: Hongru Zhang <zhanghongru06@...il.com>
Cc: akpm@...ux-foundation.org, vbabka@...e.cz, david@...nel.org, 
	linux-mm@...ck.org, linux-kernel@...r.kernel.org, surenb@...gle.com, 
	mhocko@...e.com, jackmanb@...gle.com, hannes@...xchg.org, ziy@...dia.com, 
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, rppt@...nel.org, 
	axelrasmussen@...gle.com, yuanchu@...gle.com, weixugc@...gle.com, 
	Hongru Zhang <zhanghongru@...omi.com>
Subject: Re: [PATCH 3/3] mm: optimize free_area_empty() check using
 per-migratetype counts

On Sat, Nov 29, 2025 at 8:04 AM Barry Song <21cnbao@...il.com> wrote:
>
> On Fri, Nov 28, 2025 at 11:13 AM Hongru Zhang <zhanghongru06@...il.com> wrote:
> >
> > From: Hongru Zhang <zhanghongru@...omi.com>
> >
> > Use per-migratetype counts instead of list_empty() helps reduce a
> > few cpu instructions.
> >
> > Signed-off-by: Hongru Zhang <zhanghongru@...omi.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.

If the goal is to optimize free_area list checks and list_add,
a reasonable approach is to organize the data structure
to reduce false sharing between different mt and order entries.

struct mt_free_area {
        struct list_head        free_list;
        unsigned long           nr_free;
} ____cacheline_aligned;

struct free_area {
        struct mt_free_area     mt_free_area[MIGRATE_TYPES];
};

However, without supporting data, it’s unclear if the space increase
is justified :-)

Thanks
Barry