From: Michal Hocko <mhocko@suse.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Andrew Morton <akpm@linux-foundation.org>,
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>,
Meta kernel team <kernel-team@meta.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org,
syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com
Subject: Re: [PATCH 1/9] memcg: make the v1 soft limit knob inert
Date: Thu, 13 Aug 2026 10:22:57 +0200 [thread overview]
Message-ID: <an1-4Rgwlsfd9Hjt@tiehlicka> (raw)
In-Reply-To: <20260811203203.3456029-2-shakeel.butt@linux.dev>
On Tue 11-08-26 13:31:55, Shakeel Butt wrote:
> The v1 soft limit has been deprecated since v6.12 and nobody has
> reported depending on it. Start the removal by decoupling the interface
> from the implementation: keep memory.soft_limit_in_bytes, but ignore
> writes to it and always report the maximum value on read similar to
> what memory.kmem.limit_in_bytes already does.
>
> Writes are still parsed, so malformed input keeps returning -EINVAL.
> The knob now also behaves the same everywhere: it used to return
> -EOPNOTSUPP on PREEMPT_RT, where soft limit reclaim has always been
> disabled.
Is there any specific reason to not return EOPNOTSUPP for everybody now?
> This also fixes the syzbot report linked below. Soft limit reclaim is
> the only caller that runs shrink_lruvec() from kswapd against a
> specific memcg, so it is the only way to reach lru_gen_shrink_lruvec()
> and in turn set_mm_walk(), which warns when called from kswapd.
>
> Reported-by: syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a7a6929.b50370da.49fe0.005e.GAE@google.com/
> Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
Anyway
Acked-by: Michal Hocko <mhocko@suse.com>
> ---
> .../admin-guide/cgroup-v1/memory.rst | 49 +++----------------
> mm/memcontrol-v1.c | 43 +++++++++-------
> 2 files changed, 32 insertions(+), 60 deletions(-)
>
> diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst
> index 7db63c002922..7d2a44af52c9 100644
> --- a/Documentation/admin-guide/cgroup-v1/memory.rst
> +++ b/Documentation/admin-guide/cgroup-v1/memory.rst
> @@ -47,7 +47,6 @@ Features:
> - pages are linked to per-memcg LRU exclusively, and there is no global LRU.
> - optionally, memory+swap usage can be accounted and limited.
> - hierarchical accounting
> - - soft limit
> - moving (recharging) account at moving a task is selectable.
> - usage threshold notifier
> - memory pressure notifier
> @@ -76,10 +75,9 @@ Brief summary of control files.
> memory.memsw.failcnt show the number of memory+Swap hits limits
> memory.max_usage_in_bytes show max memory usage recorded
> memory.memsw.max_usage_in_bytes show max memory+Swap usage recorded
> - memory.soft_limit_in_bytes set/show soft limit of memory usage
> - This knob is not available on CONFIG_PREEMPT_RT systems.
> - This knob is deprecated and shouldn't be
> - used.
> + memory.soft_limit_in_bytes This knob is deprecated and has no effect.
> + Writes are ignored and reads always
> + return the maximum value.
> memory.stat show various statistics
> memory.use_hierarchy set/show hierarchical account enabled
> This knob is deprecated and shouldn't be
> @@ -340,9 +338,6 @@ memory.kmem.usage_in_bytes, or in a separate counter when it makes sense.
> The main "kmem" counter is fed into the main counter, so kmem charges will
> also be visible from the user counter.
>
> -Currently no soft limit is implemented for kernel memory. It is future work
> -to trigger slab reclaim when those limits are reached.
> -
> 2.7.1 Current Kernel Memory resources accounted
> -----------------------------------------------
>
> @@ -710,42 +705,10 @@ For compatibility reasons writing 1 to memory.use_hierarchy will always pass::
>
> THIS IS DEPRECATED!
>
> -Soft limits allow for greater sharing of memory. The idea behind soft limits
> -is to allow control groups to use as much of the memory as needed, provided
> -
> -a. There is no memory contention
> -b. They do not exceed their hard limit
> -
> -When the system detects memory contention or low memory, control groups
> -are pushed back to their soft limits. If the soft limit of each control
> -group is very high, they are pushed back as much as possible to make
> -sure that one control group does not starve the others of memory.
> -
> -Please note that soft limits is a best-effort feature; it comes with
> -no guarantees, but it does its best to make sure that when memory is
> -heavily contended for, memory is allocated based on the soft limit
> -hints/setup. Currently soft limit based reclaim is set up such that
> -it gets invoked from balance_pgdat (kswapd).
> -
> -7.1 Interface
> --------------
> -
> -Soft limits can be setup by using the following commands (in this example we
> -assume a soft limit of 256 MiB)::
> -
> - # echo 256M > memory.soft_limit_in_bytes
> -
> -If we want to change this to 1G, we can at any time use::
> +Writing to memory.soft_limit_in_bytes has no effect and reading it will
> +always return the maximum value.
>
> - # echo 1G > memory.soft_limit_in_bytes
> -
> -.. note::
> - Soft limits take effect over a long period of time, since they involve
> - reclaiming memory for balancing between memory cgroups
> -
> -.. note::
> - It is recommended to set the soft limit always below the hard limit,
> - otherwise the hard limit will take precedence.
> +Use memory.low and memory.min in cgroup v2 instead.
>
> .. _cgroup-v1-memory-move-charges:
>
> diff --git a/mm/memcontrol-v1.c b/mm/memcontrol-v1.c
> index 835fc8e51184..05ef55cae4dc 100644
> --- a/mm/memcontrol-v1.c
> +++ b/mm/memcontrol-v1.c
> @@ -96,7 +96,6 @@ enum {
> RES_LIMIT,
> RES_MAX_USAGE,
> RES_FAILCNT,
> - RES_SOFT_LIMIT,
> };
>
> #ifdef CONFIG_LOCKDEP
> @@ -1888,6 +1887,30 @@ static int mem_cgroup_hierarchy_write(struct cgroup_subsys_state *css,
> return -EINVAL;
> }
>
> +static u64 mem_cgroup_soft_limit_read(struct cgroup_subsys_state *css,
> + struct cftype *cft)
> +{
> + return (u64)PAGE_COUNTER_MAX * PAGE_SIZE;
> +}
> +
> +static ssize_t mem_cgroup_soft_limit_write(struct kernfs_open_file *of,
> + char *buf, size_t nbytes, loff_t off)
> +{
> + unsigned long nr_pages;
> + int ret;
> +
> + ret = page_counter_memparse(strstrip(buf), "-1", &nr_pages);
> + if (ret)
> + return ret;
> +
> + pr_warn_once("soft_limit_in_bytes is deprecated and will be removed. "
> + "Writing any value to this file has no effect. "
> + "Please report your usecase to linux-mm@kvack.org if you "
> + "depend on this functionality.\n");
> +
> + return nbytes;
> +}
> +
> static u64 mem_cgroup_read_u64(struct cgroup_subsys_state *css,
> struct cftype *cft)
> {
> @@ -1924,8 +1947,6 @@ static u64 mem_cgroup_read_u64(struct cgroup_subsys_state *css,
> return (u64)counter->watermark * PAGE_SIZE;
> case RES_FAILCNT:
> return counter->failcnt;
> - case RES_SOFT_LIMIT:
> - return (u64)READ_ONCE(memcg->soft_limit) * PAGE_SIZE;
> default:
> BUG();
> }
> @@ -2020,17 +2041,6 @@ static ssize_t mem_cgroup_write(struct kernfs_open_file *of,
> break;
> }
> break;
> - case RES_SOFT_LIMIT:
> - if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> - ret = -EOPNOTSUPP;
> - } else {
> - pr_warn_once("soft_limit_in_bytes is deprecated and will be removed. "
> - "Please report your usecase to linux-mm@kvack.org if you "
> - "depend on this functionality.\n");
> - WRITE_ONCE(memcg->soft_limit, nr_pages);
> - ret = 0;
> - }
> - break;
> }
> return ret ?: nbytes;
> }
> @@ -2384,9 +2394,8 @@ struct cftype mem_cgroup_legacy_files[] = {
> },
> {
> .name = "soft_limit_in_bytes",
> - .private = MEMFILE_PRIVATE(_MEM, RES_SOFT_LIMIT),
> - .write = mem_cgroup_write,
> - .read_u64 = mem_cgroup_read_u64,
> + .write = mem_cgroup_soft_limit_write,
> + .read_u64 = mem_cgroup_soft_limit_read,
> },
> {
> .name = "failcnt",
> --
> 2.53.0-Meta
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2026-08-13 8:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 20:31 [PATCH for-7.4 0/9] memcg: remove the v1 soft limit Shakeel Butt
2026-08-11 20:31 ` [PATCH 1/9] memcg: make the v1 soft limit knob inert Shakeel Butt
2026-08-12 22:50 ` Andrew Morton
2026-08-12 23:40 ` Shakeel Butt
2026-08-13 8:22 ` Michal Hocko [this message]
2026-08-11 20:31 ` [PATCH 2/9] memcg: remove v1 soft limit reclaim Shakeel Butt
2026-08-13 8:24 ` Michal Hocko
2026-08-11 20:31 ` [PATCH 3/9] memcg: remove mem_cgroup_shrink_node() Shakeel Butt
2026-08-13 8:24 ` Michal Hocko
2026-08-11 20:31 ` [PATCH 4/9] memcg: remove the soft limit reclaim tracepoints Shakeel Butt
2026-08-13 8:25 ` Michal Hocko
2026-08-11 20:31 ` [PATCH 5/9] memcg: remove the soft limit rbtree Shakeel Butt
2026-08-13 8:25 ` Michal Hocko
2026-08-11 20:32 ` [PATCH 6/9] memcg: remove lru_gen_soft_reclaim() Shakeel Butt
2026-08-13 8:26 ` Michal Hocko
2026-08-11 20:32 ` [PATCH 7/9] memcg: remove the per-node soft limit tree fields Shakeel Butt
2026-08-13 8:27 ` Michal Hocko
2026-08-11 20:32 ` [PATCH 8/9] memcg: remove mem_cgroup->soft_limit Shakeel Butt
2026-08-13 8:27 ` Michal Hocko
2026-08-11 20:32 ` [PATCH 9/9] memcg: simplify v1 event ratelimiting Shakeel Butt
2026-08-13 8:28 ` Michal Hocko
2026-08-13 9:27 ` [PATCH for-7.4 0/9] memcg: remove the v1 soft limit Lorenzo Stoakes (ARM)
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=an1-4Rgwlsfd9Hjt@tiehlicka \
--to=mhocko@suse.com \
--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=muchun.song@linux.dev \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=syzbot+12ee2725d5fde63a9c96@syzkaller.appspotmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox