From: Michal Hocko <mhocko@suse.com>
To: zangchunxin@bytedance.com
Cc: hannes@cmpxchg.org, vdavydov.dev@gmail.com,
akpm@linux-foundation.org, tj@kernel.org, lizefan@huawei.com,
corbet@lwn.net, ast@kernel.org, daniel@iogearbox.net,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com, andriin@fb.com,
john.fastabend@gmail.com, kpsingh@chromium.org,
cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2
Date: Mon, 21 Sep 2020 10:12:00 +0200 [thread overview]
Message-ID: <20200921081200.GE12990@dhcp22.suse.cz> (raw)
In-Reply-To: <20200921080255.15505-1-zangchunxin@bytedance.com>
On Mon 21-09-20 16:02:55, zangchunxin@bytedance.com wrote:
> From: Chunxin Zang <zangchunxin@bytedance.com>
>
> In the cgroup v1, we have 'force_mepty' interface. This is very
> useful for userspace to actively release memory. But the cgroup
> v2 does not.
>
> This patch reuse cgroup v1's function, but have a new name for
> the interface. Because I think 'drop_cache' may be is easier to
> understand :)
This should really explain a usecase. Global drop_caches is a terrible
interface and it has caused many problems in the past. People have
learned to use it as a remedy to any problem they might see and cause
other problems without realizing that. This is the reason why we even
log each attempt to drop caches.
I would rather not repeat the same mistake on the memcg level unless
there is a very strong reason for it.
> Signed-off-by: Chunxin Zang <zangchunxin@bytedance.com>
> ---
> Documentation/admin-guide/cgroup-v2.rst | 11 +++++++++++
> mm/memcontrol.c | 5 +++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> index ce3e05e41724..fbff959c8116 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -1181,6 +1181,17 @@ PAGE_SIZE multiple when read back.
> high limit is used and monitored properly, this limit's
> utility is limited to providing the final safety net.
>
> + memory.drop_cache
> + A write-only single value file which exists on non-root
> + cgroups.
> +
> + Provide a mechanism for users to actively trigger memory
> + reclaim. The cgroup will be reclaimed and as many pages
> + reclaimed as possible.
> +
> + It will broke low boundary. Because it tries to reclaim the
> + memory many times, until the memory drops to a certain level.
> +
> memory.oom.group
> A read-write single value file which exists on non-root
> cgroups. The default value is "0".
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 0b38b6ad547d..98646484efff 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6226,6 +6226,11 @@ static struct cftype memory_files[] = {
> .write = memory_max_write,
> },
> {
> + .name = "drop_cache",
> + .flags = CFTYPE_NOT_ON_ROOT,
> + .write = mem_cgroup_force_empty_write,
> + },
> + {
> .name = "events",
> .flags = CFTYPE_NOT_ON_ROOT,
> .file_offset = offsetof(struct mem_cgroup, events_file),
> --
> 2.11.0
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-09-21 8:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 8:02 zangchunxin
2020-09-21 8:12 ` Michal Hocko [this message]
2020-09-21 10:42 ` Chris Down
2020-09-21 10:55 ` Yafang Shao
2020-09-21 11:05 ` Michal Hocko
2020-09-21 11:23 ` Yafang Shao
2020-09-21 11:36 ` Michal Hocko
2020-09-22 4:20 ` Yafang Shao
2020-09-22 7:27 ` Michal Hocko
2020-09-22 8:06 ` Yafang Shao
2020-09-22 10:01 ` Michal Hocko
2020-09-22 9:43 ` [External] " Chunxin Zang
2020-09-22 9:51 ` Chris Down
2020-09-22 10:24 ` Chunxin Zang
2020-09-22 10:42 ` Chris Down
2020-09-22 12:37 ` Chunxin Zang
2020-09-22 12:43 ` Chris Down
2020-09-23 2:35 ` Chunxin Zang
2020-09-22 19:57 ` Shakeel Butt
2020-09-23 2:40 ` Chunxin Zang
2020-09-21 15:55 ` Shakeel Butt
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=20200921081200.GE12990@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=hannes@cmpxchg.org \
--cc=john.fastabend@gmail.com \
--cc=kafai@fb.com \
--cc=kpsingh@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=songliubraving@fb.com \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=yhs@fb.com \
--cc=zangchunxin@bytedance.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