lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 22 Sep 2020 20:37:32 +0800
From:   Chunxin Zang <>
To:     Chris Down <>
Cc:     Michal Hocko <>, Yafang Shao <>,
        Johannes Weiner <>,
        Vladimir Davydov <>,
        Andrew Morton <>,
        Tejun Heo <>,,
        Jonathan Corbet <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,,
        Song Liu <>, Yonghong Song <>,,,,
        Cgroups <>,,
        Linux MM <>,
        LKML <>,
        netdev <>,
Subject: Re: [External] Re: [PATCH] mm/memcontrol: Add the drop_cache
 interface for cgroup v2

On Tue, Sep 22, 2020 at 6:42 PM Chris Down <> wrote:
> Chunxin Zang writes:
> >On Tue, Sep 22, 2020 at 5:51 PM Chris Down <> wrote:
> >>
> >> Chunxin Zang writes:
> >> >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.
> >>
> >> This sounds like a perfect use case for memory.low on Type_A, and it's pretty
> >> much exactly what we invented it for. What's the problem with that?
> >
> >But we cannot estimate how much memory Type_A uses at least.
> memory.low allows ballparking, you don't have to know exactly how much it uses.
> Any amount of protection biases reclaim away from that cgroup.
> >For example:
> >total memory: 100G
> >At the beginning, Type_A was in an idle state, and it only used 10G of memory.
> >The load is very low. We want to run Type_B to avoid wasting machine resources.
> >When Type_B runs for a while, it used 80G of memory.
> >At this time Type_A is busy, it needs more memory.
> Ok, so set memory.low for Type_A close to your maximum expected value.

Please forgive me for not being able to understand why setting
memory.low for Type_A can solve the problem.
In my scene, Type_A is the most important, so I will set 100G to memory.low.
But 'memory.low' only takes effect passively when the kernel is
reclaiming memory. It means that reclaim Type_B's memory only when
Type_A  in alloc memory slow path. This will affect Type_A's
We want to reclaim Type_B's memory in advance when A is expected to be busy.

Best wishes

Powered by blists - more mailing lists