From: Andrew Morton <akpm@linux-foundation.org>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>,
Yosry Ahmed <yosry@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
cgroups@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3 0/2] memcg: reduce cacheline contention from lruvec stat
Date: Tue, 27 Oct 2026 19:24:14 -0700 [thread overview]
Message-ID: <20261027192414.cb3318abc07232ec5f1bc937@linux-foundation.org> (raw)
In-Reply-To: <CAJnrk1Z-zzKL9Jebk4XMpfOBtyArppGPTv3__GTbCZXGiEJjOQ@mail.gmail.com>
On Tue, 27 Oct 2026 15:57:43 -0700 Joanne Koong <joannelkoong@gmail.com> wrote:
> Here's an updated version of the "Fix this by moving the memcg_pn_cold
> group..." paragraph in patch 1 that mentions this:
>
> Fix this by moving the memcg_pn_cold group, which is only touched when
> the memcg is reparented or freed, right after memcg_pn_read_mostly.
> SLAB_HWCACHE_ALIGN only aligns objects to a cacheline, and the struct
> is 576 bytes, so depending on where an object lands, its read-mostly
> cacheline is now paired either with its cold cacheline or with the last
> cacheline of the preceding object, which holds the end of
> lru_zone_size[] and the reclaim iterator. Both are rarely written
> outside of reclaim, so either way the read-mostly cacheline is no
> longer paired with the LRU list heads.
>
> Would you be able to swap it in or would you prefer that I send a v4?
Thanks. I'll take care of this when I process the patchset. Which
will be quite soon now we're all merged up.
next prev parent reply other threads:[~2026-10-28 2:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 19:54 [PATCH v3 0/2] memcg: reduce cacheline contention from lruvec stat Joanne Koong
2026-10-23 19:54 ` [PATCH v3 1/2] memcg: reduce cacheline contention between lruvec stat updates and LRU lists Joanne Koong
2026-10-26 9:29 ` Michal Hocko
2026-10-23 19:54 ` [PATCH v3 2/2] memcg: don't go through the lruvec for folio and kmem lruvec stat updates Joanne Koong
2026-10-26 9:38 ` Michal Hocko
2026-10-23 22:54 ` [PATCH v3 0/2] memcg: reduce cacheline contention from lruvec stat Andrew Morton
2026-10-27 22:57 ` Joanne Koong
2026-10-28 2:24 ` Andrew Morton [this message]
2026-10-28 18:33 ` Joanne Koong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261027192414.cb3318abc07232ec5f1bc937@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=joannelkoong@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=yosry@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.