linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Xunlei Pang <xlpang@linux.alibaba.com>
Cc: Roman Gushchin <guro@fb.com>, Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] memcg: Ignore unprotected parent in mem_cgroup_protected()
Date: Sun, 16 Jun 2019 00:08:20 +0800	[thread overview]
Message-ID: <20190615160820.GB1307@chrisdown.name> (raw)
In-Reply-To: <20190615111704.63901-1-xlpang@linux.alibaba.com>

Hi Xunlei,

Xunlei Pang writes:
>Currently memory.min|low implementation requires the whole
>hierarchy has the settings, otherwise the protection will
>be broken.
>
>Our hierarchy is kind of like(memory.min value in brackets),
>
>               root
>                |
>             docker(0)
>              /    \
>         c1(max)   c2(0)
>
>Note that "docker" doesn't set memory.min. When kswapd runs,
>mem_cgroup_protected() returns "0" emin for "c1" due to "0"
>@parent_emin of "docker", as a result "c1" gets reclaimed.
>
>But it's hard to maintain parent's "memory.min" when there're
>uncertain protected children because only some important types
>of containers need the protection.  Further, control tasks
>belonging to parent constantly reproduce trivial memory which
>should not be protected at all.  It makes sense to ignore
>unprotected parent in this scenario to achieve the flexibility.

I'm really confused by this, why don't you just set memory.{min,low} in the 
docker cgroup and only propagate it to the children that want it?

If you only want some children to have the protection, only request it in those 
children, or create an additional intermediate layer of the cgroup hierarchy 
with protections further limited if you don't trust the task to request the 
right amount.

Breaking the requirement for hierarchical propagation of protections seems like 
a really questionable API change, not least because it makes it harder to set 
systemwide policies about the constraints of protections within a subtree.


  reply	other threads:[~2019-06-15 16:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-15 11:17 Xunlei Pang
2019-06-15 16:08 ` Chris Down [this message]
2019-06-16  6:30   ` Xunlei Pang
2019-06-16 10:37     ` Chris Down
2019-06-16 11:57       ` Xunlei Pang

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=20190615160820.GB1307@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=xlpang@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