From: Michal Hocko <mhocko@kernel.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>, Chris Down <chris@chrisdown.name>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH 0/3] mm: improve proportional memcg protection
Date: Tue, 28 Apr 2020 10:05:25 +0200 [thread overview]
Message-ID: <20200428080525.GL28637@dhcp22.suse.cz> (raw)
In-Reply-To: <CALOAHbANpfiLxn+9eYLDQqiOqydmNesNaLU7OBduRP+UXVUVZw@mail.gmail.com>
On Tue 28-04-20 09:45:27, Yafang Shao wrote:
[...]
> Seems we can't get an agreement on how to improve current code.
> So I will submit a patch to revert the commit 9783aa9917f8 ("mm,
> memcg: proportional memory.{low,min} reclaim") first.
My current understanding is that the issue we are discussing here is
mostly theoretical. Your changelog doesn't really talk about any real
life workloads that would be suffering. While it is possible to construct
one that misbehaves it is really important to know whether this actually
happens in real life. My guess would be that it is not because nax/high
limits do not tend to be close to protection usually.
With that in mind I do not really believe that reverting 9783aa9917f8
is a reasonable approach. Try to weigh pros and cons of the
functionality. Useful functionality for reasonable setups vs. potential
corner cases which are not really likely.
Please also note that we might disagree on implementation details
because people usually have very different taste for code. But it seems
that we are in agreement with Johannes that your patch does not really
improve the overall situation all that much while it adds stuff that we
actively disagree with.
So it would be really more helpful to not insist on unrelated
implementation details and focus on two things 1) split up the effective
values calculation from the predicate (cleanup without any functional
changes) 2) make the calculation more robust against racing reclaimers.
I plan to get to this unless you beat me to it.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-04-28 8:05 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 15:24 Yafang Shao
2020-04-25 15:24 ` [PATCH 1/3] mm: move struct scan_control into internal.h Yafang Shao
2020-04-25 15:24 ` [PATCH 2/3] mm: add reclaim context as a new parameter in mem_cgroup_protected() Yafang Shao
2020-04-25 15:24 ` [PATCH 3/3] mm: improvements on memcg protection functions Yafang Shao
2020-04-27 9:40 ` Michal Hocko
2020-04-27 10:09 ` Yafang Shao
2020-04-27 10:50 ` Michal Hocko
2020-04-27 11:06 ` Yafang Shao
2020-04-27 11:24 ` Michal Hocko
2020-04-27 11:32 ` Yafang Shao
2020-04-27 17:05 ` [PATCH 0/3] mm: improve proportional memcg protection Johannes Weiner
2020-04-28 1:45 ` Yafang Shao
2020-04-28 3:37 ` Johannes Weiner
2020-04-28 6:00 ` Yafang Shao
2020-04-28 8:05 ` Michal Hocko [this message]
2020-04-28 8:22 ` Yafang Shao
2020-04-28 10:43 ` Michal Hocko
2020-04-28 12:25 ` Yafang Shao
2020-04-28 12:42 ` Michal Hocko
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=20200428080525.GL28637@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=chris@chrisdown.name \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
/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