Thread (21 messages) 21 messages, 5 authors, 2020-09-23

Re: [External] Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2

From: Chunxin Zang <hidden>
Date: 2020-09-22 09:44:07
Also in: bpf, cgroups, linux-doc, linux-mm, lkml

On Mon, Sep 21, 2020 at 7:05 PM Michal Hocko [off-list ref] wrote:
On Mon 21-09-20 18:55:40, Yafang Shao wrote:
quoted
On Mon, Sep 21, 2020 at 4:12 PM Michal Hocko [off-list ref] wrote:
quoted
On Mon 21-09-20 16:02:55, zangchunxin@bytedance.com wrote:
quoted
From: Chunxin Zang <redacted>

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.
I think we'd better add these comments above the function
mem_cgroup_force_empty() to explain why we don't want to expose this
interface in cgroup2, otherwise people will continue to send this
proposal without any strong reason.
I do not mind people sending this proposal.  "V1 used to have an
interface, we need it in v2 as well" is not really viable without
providing more reasoning on the specific usecase.

_Any_ patch should have a proper justification. This is nothing really
new to the process and I am wondering why this is coming as a surprise.
I'm so sorry for that.
My usecase is that there are two types of services in one server. They
have difference
priorities. Type_A has the highest priority, we need to ensure it's
schedule latency、I/O
latency、memory enough. Type_B has the lowest priority, we expect it
will not affect
Type_A when executed.
So Type_A could use memory without any limit. Type_B could use memory
only when the
memory is absolutely sufficient. But we cannot estimate how much
memory Type_B should
use. Because everything is dynamic. So we can't set Type_B's memory.high.

So we want to release the memory of Type_B when global memory is
insufficient in order
to ensure the quality of service of Type_A . In the past, we used the
'force_empty' interface
of cgroup v1.
--
Michal Hocko
SUSE Labs
Best wishes
Chunxin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help