From: Chris Down <chris@chrisdown.name>
To: Hui Zhu <teawaterz@linux.alibaba.com>
Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com,
akpm@linux-foundation.org, guro@fb.com, shakeelb@google.com,
yang.shi@linux.alibaba.com, tj@kernel.org, tglx@linutronix.de,
linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: vmscan: memcg: Add global shrink priority
Date: Wed, 18 Dec 2019 14:09:52 +0000 [thread overview]
Message-ID: <20191218140952.GA255739@chrisdown.name> (raw)
In-Reply-To: <1576662179-16861-1-git-send-email-teawaterz@linux.alibaba.com>
Hi Hui,
In general cgroup v1 is in maintenance mode -- that is, excepting specific
bugfixes, we don't plan to add new features.
Hui Zhu writes:
>Currently, memcg has some config to limit memory usage and config
>the shrink behavior.
>In the memory-constrained environment, put different priority tasks
>into different cgroups with different memory limits to protect the
>performance of the high priority tasks. Because the global memory
>shrink will affect the performance of all tasks. The memory limit
>cgroup can make shrink happen inside the cgroup. Then it can decrease
>the memory shrink of the high priority task to protect its performance.
>
>But the memory footprint of the task is not static. It will change as
>the working pressure changes. And the version changes will affect it too.
>Then set the appropriate memory limit to decrease the global memory shrink
>is a difficult job and lead to wasted memory or performance loss sometimes.
>
>This commit adds global shrink priority to memcg to try to handle this
>problem.
I have significant concerns with exposing scan priority to userspace. This is
an incredibly difficult metric for users to reason about since it's a reclaim
implementation feature and would add to an already confusing and fragmented API
in v1.
Have you considered using memory protection (memory.low, memory.min) for this
instead? It sounds like it can achieve the results you want, in that it allows
you to direct and prioritise reclaim in a way that allows for ballparking (ie.
it is compatible with applications with variable memory footprints).
Thanks,
Chris
next prev parent reply other threads:[~2019-12-18 14:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 9:42 [PATCH] mm: vmscan: memcg: Add global shrink priority Hui Zhu
2019-12-18 10:47 ` Yafang Shao
2019-12-19 9:04 ` teawater
2019-12-18 14:09 ` Chris Down [this message]
2019-12-19 8:59 ` teawater
2019-12-19 11:26 ` Chris Down
2019-12-20 7:48 ` teawater
2019-12-29 13:38 ` teawater
2019-12-29 14:02 ` Chris Down
2019-12-30 3:32 ` 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=20191218140952.GA255739@chrisdown.name \
--to=chris@chrisdown.name \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=shakeelb@google.com \
--cc=teawaterz@linux.alibaba.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vdavydov.dev@gmail.com \
--cc=yang.shi@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).