From: Michal Hocko <mhocko@suse.com>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Suren Baghdasaryan <surenb@google.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
cgroups mailinglist <cgroups@vger.kernel.org>,
Ke Wang <ke.wang@unisoc.com>
Subject: Re: [RFC PATCH] cgroup: introduce dynamic protection for memcg
Date: Mon, 4 Apr 2022 10:51:48 +0200 [thread overview]
Message-ID: <YkqxpEW4m6iU3zMq@dhcp22.suse.cz> (raw)
In-Reply-To: <CAGWkznFTQCm0cusVxA_55fu2WfT-w2coVHrT=JA1D_9_2728mQ@mail.gmail.com>
On Mon 04-04-22 10:33:58, Zhaoyang Huang wrote:
[...]
> > One thing that I don't understand in this approach is: why memory.low
> > should depend on the system's memory pressure. It seems you want to
> > allow a process to allocate more when memory pressure is high. That is
> > very counter-intuitive to me. Could you please explain the underlying
> > logic of why this is the right thing to do, without going into
> > technical details?
> What I want to achieve is make memory.low be positive correlation with
> timing and negative to memory pressure, which means the protected
> memcg should lower its protection(via lower memcg.low) for helping
> system's memory pressure when it's high.
I have to say this is still very confusing to me. The low limit is a
protection against external (e.g. global) memory pressure. Decreasing
the protection based on the external pressure sounds like it goes right
against the purpose of the knob. I can see reasons to update protection
based on refaults or other metrics from the userspace but I still do not
see how this is a good auto-magic tuning done by the kernel.
> The concept behind is memcg's
> fault back of dropped memory is less important than system's latency
> on high memory pressure.
Can you give some specific examples?
> Please refer to my new version's test data
> for more detail.
Please note that sending new RFCs will just make the discussion spread
over several email threads which will get increasingly hard to follow.
So do not post another version until it is really clear what is the
actual semantic you are proposing.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-04-04 8:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-31 8:00 [RFC PATCH] cgroup: introduce dynamic protection for memcg zhaoyang.huang
2022-03-31 9:01 ` Michal Hocko
2022-03-31 11:18 ` Zhaoyang Huang
2022-03-31 11:35 ` Michal Hocko
2022-03-31 19:26 ` Suren Baghdasaryan
2022-04-01 1:51 ` Zhaoyang Huang
2022-04-01 4:46 ` Suren Baghdasaryan
2022-04-02 3:21 ` Zhaoyang Huang
2022-04-01 1:34 ` Zhaoyang Huang
2022-04-01 11:34 ` Michal Hocko
2022-04-02 5:18 ` Zhaoyang Huang
2022-04-03 15:04 ` Suren Baghdasaryan
2022-04-04 2:33 ` Zhaoyang Huang
2022-04-04 8:51 ` Michal Hocko [this message]
2022-04-04 9:07 ` Zhaoyang Huang
2022-04-04 9:23 ` Zhaoyang Huang
2022-04-04 9:32 ` Michal Hocko
2022-04-04 9:36 ` Michal Hocko
2022-04-04 11:35 ` Zhaoyang Huang
2022-04-04 11:23 ` Zhaoyang Huang
2022-04-04 12:29 ` Michal Hocko
2022-04-04 13:14 ` Zhaoyang Huang
2022-04-05 12:08 ` Michal Hocko
2022-04-06 2:11 ` Zhaoyang Huang
2022-04-07 7:40 ` Michal Hocko
2022-04-07 8:59 ` Zhaoyang Huang
2022-04-07 9:44 ` Michal Hocko
2022-04-07 12:36 ` Zhaoyang Huang
2022-04-07 14:14 ` Michal Hocko
2022-04-06 8:21 ` Zhaoyang Huang
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=YkqxpEW4m6iU3zMq@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=huangzhaoyang@gmail.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=surenb@google.com \
--cc=vdavydov.dev@gmail.com \
--cc=zhaoyang.huang@unisoc.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