Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <Yjx/3yi7BfH7wLPz@chrisdown.name> <FE4CCCF9-CF08-424B-85D0-B5C1BA63329D@linux.dev>
In-Reply-To: <FE4CCCF9-CF08-424B-85D0-B5C1BA63329D@linux.dev>
From:   Zhaoyang Huang <huangzhaoyang@gmail.com>
Date:   Fri, 25 Mar 2022 11:10:19 +0800
Message-ID: <CAGWkznGnDUvAqX3KCP+HZCyn49XU9=2bV9vfiFbutsQw8mK=hw@mail.gmail.com>
Subject: Re: [RFC PATCH] cgroup: introduce proportional protection on memcg
To:     Roman Gushchin <roman.gushchin@linux.dev>
Cc:     Chris Down <chris@chrisdown.name>,
        "zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@kernel.org>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        ke wang <ke.wang@unisoc.com>,
        "open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>, cgroups@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Mar 25, 2022 at 12:23 AM Roman Gushchin
<roman.gushchin@linux.dev> wrote:
>
> It seems like what=E2=80=99s being proposed is an ability to express the =
protection in % of the current usage rather than an absolute number.
> It=E2=80=99s an equivalent for something like a memory (reclaim) priority=
: e.g. a cgroup with 80% protection is _always_ reclaimed less aggressively=
 than one with a 20% protection.
>
> That said, I=E2=80=99m not a fan of this idea.
> It might make sense in some reasonable range of usages, but if your workl=
oad is simply leaking memory and growing indefinitely, protecting it seems =
like a bad idea. And the first part can be easily achieved using an userspa=
ce tool.
>
> Thanks!
>
> > On Mar 24, 2022, at 7:33 AM, Chris Down <chris@chrisdown.name> wrote:
> >
> > =EF=BB=BFI'm confused by the aims of this patch. We already have propor=
tional reclaim for memory.min and memory.low, and memory.high is already "p=
roportional" by its nature to drive memory back down behind the configured =
threshold.
> >
> > Could you please be more clear about what you're trying to achieve and =
in what way the existing proportional reclaim mechanisms are insufficient f=
or you?
ok, I think it could be fixable for memory leak issues. Please refer
to my reply on Chris's comment for more explanation.