Re: [PATCH v3 0/2] memcg: reduce cacheline contention from lruvec stat

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 23 Oct 2026 12:54:15 -0700 Joanne Koong <joannelkoong@gmail.com> wrote:

> Memcg lruvec stat updates read fields of struct mem_cgroup_per_node and struct
> lruvec that can share a 128-byte cacheline pair with lines the lru_lock holder
> writes constantly (the LRU list heads, lru_lock or lru_zone_size[]), depending
> on where struct mem_cgroup_per_node lands in its slab. On CPUs that do spatial
> prefetching (eg Intel CPUs), this makes the stat updates contend with the
> lru_lock holder.
> 
> Patch 1 rearranges struct mem_cgroup_per_node so that its read-mostly line is
> paired with a cold line, and patch 2 makes the folio and kmem stat updates use
> the memcg and node they already know instead of going through the lruvec,
> whose pgdat field shares a cacheline pair with lru_lock or lru_zone_size[].
> 
> Results on a 2-socket Skylake (80 CPUs), average pages per second for
> threads faulting in and freeing memory in a single memcg:
> 
> 	   base     patch 1   patch 1+2 
> shmem, 20 threads  4.74M    5.59M     5.77M
> shmem, 80 threads  7.94M    8.66M     8.82M
> anon,  20 threads  3.04M    3.08M     3.10M

Thanks.  A local AI review pointed out a thing:

  One limitation worth mentioning in the [1/2] changelog: the slab
  uses SLAB_HWCACHE_ALIGN, which need not align each object to a
  128-byte boundary.  If an object starts 64 bytes into such a pair,
  its first line can still be paired with the end of the preceding
  object rather than its own cold line.  This isn't a correctness
  issue, and the measured Skylake improvement may well be real, but the
  layout doesn't guarantee that every read-mostly line pairs with a
  cold line.