From: Michal Hocko <mhocko@kernel.org>
To: Chris Down <chris@chrisdown.name>
Cc: Hui Zhu <teawater@gmail.com>,
hannes@cmpxchg.org, vdavydov.dev@gmail.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, linux-mm@kvack.org,
Hui Zhu <teawaterz@linux.alibaba.com>
Subject: Re: [RFC] memcg: Add swappiness to cgroup2
Date: Mon, 6 Jan 2020 14:10:20 +0100 [thread overview]
Message-ID: <20200106131020.GC9198@dhcp22.suse.cz> (raw)
In-Reply-To: <20191225140546.GA311630@chrisdown.name>
On Wed 25-12-19 14:05:46, Chris Down wrote:
> Hi Hui,
>
> Hui Zhu writes:
> > Even if cgroup2 has swap.max, swappiness is still a very useful config.
> > This commit add swappiness to cgroup2.
>
> When submitting patches like this, it's important to explain *why* you want
> it and what evidence there is. For example, how should one use this to
> compose a reasonable system? Why aren't existing protection controls
> sufficient for your use case? Where's the data?
Agreed!
> Also, why would swappiness be something cgroup-specific instead of
> hardware-specific, when desired swappiness is really largely about the
> hardware you have in your system?
I am not really sure I agree here though. Swappiness has been
traditionally more about workload because it has been believed that it
is a preference of the workload whether the anonymous or disk based
memory is more important. Whether this is a good interface is debatable
of course but time has shown that it is extremely hard to tune.
Not to mention that swappiness has been ignored for years for vast
majority workloads because of the highly biased file LRU reclaim.
At the time when cgroup v2 was introduced it'd been claimed that we
do not want to copy the v1 swappiness logic because of the semantic
shortcomings and that a better tuning should developed in future
replacing even the global knob. AFAIR Johannes wanted to have a refault
vs. cost based file/anon balancing.
The lack of a sensible hierarchical behavior has been even a stronger
argument.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-01-06 13:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-25 5:36 [RFC] memcg: Add swappiness to cgroup2 Hui Zhu
2019-12-25 14:05 ` Chris Down
2019-12-26 6:56 ` teawater
2020-01-03 9:48 ` Michal Koutný
2020-01-06 13:10 ` Michal Hocko [this message]
2020-01-06 13:24 ` Chris Down
2019-12-31 23:16 ` Andrew Morton
2020-01-02 1:44 ` teawater
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=20200106131020.GC9198@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris@chrisdown.name \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=teawater@gmail.com \
--cc=teawaterz@linux.alibaba.com \
--cc=vdavydov.dev@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.