From: Shakeel Butt <shakeel.butt@linux.dev>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
tjmercier@google.com, Meta kernel team <kernel-team@meta.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/8] memcg: remove the v1 soft limit
Date: Wed, 2 Sep 2026 10:43:03 -0700 [thread overview]
Message-ID: <20260902174311.1772372-1-shakeel.butt@linux.dev> (raw)
The v1 soft limit was deprecated in v6.12 by commit 569c4f62d84a ("memcg:
initiate deprecation of v1 soft limit") and nobody has reported depending
on it in the ~21 months since. memory.low and memory.min in v2 have
covered the same ground for far longer.
The knob has since been made inert by "memcg: make the v1 soft limit knob
inert", already queued in mm-hotfixes as a backportable fix for a syzbot
report [1]. Nothing can enter the soft limit rbtree anymore, so this
series just deletes the machinery that is now dead: the reclaim pass in
kswapd and direct reclaim, mem_cgroup_shrink_node() and its tracepoints,
the per-node rbtree, lru_gen_soft_reclaim() and the MEMCG_LRU_HEAD op, the
per-node tree fields, mem_cgroup->soft_limit, and finally the v1 event
ratelimiting which is now down to a single target.
memory.soft_limit_in_bytes itself is untouched: writes stay ignored and
reads keep returning the maximum value.
Changes since v1 [2]:
- Dropped "memcg: make the v1 soft limit knob inert" (1/9 in v1), which is
already queued in mm-hotfixes, making this an 8-patch series.
- Collected the acks and review tags. No code changes.
Sashiko's v1 review [3] asked whether the softlimit tracepoints,
lru_gen_soft_reclaim(), the per-node tree fields and the
MEM_CGROUP_TARGET_SOFTLIMIT ratelimiting could go too. They all can and
they all do, in patches 3/8, 5/8, 6/8 and 8/8 of this same series.
[1] https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/
[2] https://lore.kernel.org/all/20260811203203.3456029-1-shakeel.butt@linux.dev/
[3] https://sashiko.dev/#/patchset/20260811203203.3456029-1-shakeel.butt@linux.dev
Shakeel Butt (8):
memcg: remove v1 soft limit reclaim
memcg: remove mem_cgroup_shrink_node()
memcg: remove the soft limit reclaim tracepoints
memcg: remove the soft limit rbtree
memcg: remove lru_gen_soft_reclaim()
memcg: remove the per-node soft limit tree fields
memcg: remove mem_cgroup->soft_limit
memcg: simplify v1 event ratelimiting
include/linux/memcontrol.h | 27 ---
include/linux/mmzone.h | 30 +--
include/trace/events/vmscan.h | 14 --
mm/internal.h | 4 -
mm/memcontrol-v1.c | 392 ++--------------------------------
mm/memcontrol-v1.h | 12 +-
mm/memcontrol.c | 7 +-
mm/vmscan.c | 96 +--------
8 files changed, 34 insertions(+), 548 deletions(-)
--
2.53.0-Meta
next reply other threads:[~2026-09-02 17:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 17:43 Shakeel Butt [this message]
2026-09-02 17:43 ` [PATCH v2 1/8] memcg: remove v1 soft limit reclaim Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 2/8] memcg: remove mem_cgroup_shrink_node() Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 3/8] memcg: remove the soft limit reclaim tracepoints Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 4/8] memcg: remove the soft limit rbtree Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 5/8] memcg: remove lru_gen_soft_reclaim() Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 6/8] memcg: remove the per-node soft limit tree fields Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 7/8] memcg: remove mem_cgroup->soft_limit Shakeel Butt
2026-09-02 17:43 ` [PATCH v2 8/8] memcg: simplify v1 event ratelimiting Shakeel Butt
2026-09-02 19:40 ` [PATCH v2 0/8] memcg: remove the v1 soft limit Andrew Morton
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=20260902174311.1772372-1-shakeel.butt@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=tjmercier@google.com \
/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.