LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <kernel-team@fb.com>,
	Michal Hocko <mhocko@suse.com>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH v3 2/2] mm: ignore memory.min of abandoned memory cgroups
Date: Thu, 10 May 2018 14:08:04 +0100	[thread overview]
Message-ID: <20180510130758.GA9129@castle.DHCP.thefacebook.com> (raw)
In-Reply-To: <20180509153805.2a940eac8c858398fb0f4b0c@linux-foundation.org>

On Wed, May 09, 2018 at 03:38:05PM -0700, Andrew Morton wrote:
> > 
> > Memory controller implements the memory.low best-effort memory
> > protection mechanism, which works perfectly in many cases and
> > allows protecting working sets of important workloads from
> > sudden reclaim.
> > 
> > But its semantics has a significant limitation: it works
> > only as long as there is a supply of reclaimable memory.
> > This makes it pretty useless against any sort of slow memory
> > leaks or memory usage increases. This is especially true
> > for swapless systems. If swap is enabled, memory soft protection
> > effectively postpones problems, allowing a leaking application
> > to fill all swap area, which makes no sense.
> > The only effective way to guarantee the memory protection
> > in this case is to invoke the OOM killer.
> > 
> > It's possible to handle this case in userspace by reacting
> > on MEMCG_LOW events; but there is still a place for a fail-safe
> > in-kernel mechanism to provide stronger guarantees.
> > 
> > This patch introduces the memory.min interface for cgroup v2
> > memory controller. It works very similarly to memory.low
> > (sharing the same hierarchical behavior), except that it's
> > not disabled if there is no more reclaimable memory in the system.
> > 
> > If cgroup is not populated, its memory.min is ignored,
> > because otherwise even the OOM killer wouldn't be able
> > to reclaim the protected memory, and the system can stall.
> > 
> > ...
> >
> > --- a/Documentation/cgroup-v2.txt
> > +++ b/Documentation/cgroup-v2.txt
> > @@ -1002,6 +1002,29 @@ PAGE_SIZE multiple when read back.
> >  	The total amount of memory currently being used by the cgroup
> >  	and its descendants.
> >  
> > +  memory.min
> > +	A read-write single value file which exists on non-root
> > +	cgroups.  The default is "0".
> > +
> > +	Hard memory protection.  If the memory usage of a cgroup
> > +	is within its effective min boundary, the cgroup's memory
> > +	won't be reclaimed under any conditions. If there is no
> > +	unprotected reclaimable memory available, OOM killer
> > +	is invoked.
> > +
> > +	Effective low boundary is limited by memory.min values of
> > +	all ancestor cgroups. If there is memory.min overcommitment
> > +	(child cgroup or cgroups are requiring more protected memory
> > +	than parent will allow), then each child cgroup will get
> > +	the part of parent's protection proportional to its
> > +	actual memory usage below memory.min.
> > +
> > +	Putting more memory than generally available under this
> > +	protection is discouraged and may lead to constant OOMs.
> > +
> > +	If a memory cgroup is not populated with processes,
> > +	its memory.min is ignored.

Hello, Andrew!

> This is a copy-paste-edit of the memory.low description.  Could we
> please carefully check that it all remains accurate?  Should "Effective
> low boundary" be "Effective min boundary"?  Does overcommit still apply
> to .min?  etcetera.

Except this s/low/min replacement (good catch, thank you! diff below),
the rest looks fine to me. Memory.min and memory.low are similar
in their hierarchical behavior, so most of the things still apply to .min.

Also, can you, please, add
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
(which was accidentally lost between versions).

Thanks you!

--

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 1764a627a120..f6725628bb4f 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -1012,7 +1012,7 @@ PAGE_SIZE multiple when read back.
        unprotected reclaimable memory available, OOM killer
        is invoked.
 
-       Effective low boundary is limited by memory.min values of
+       Effective min boundary is limited by memory.min values of
        all ancestor cgroups. If there is memory.min overcommitment
        (child cgroup or cgroups are requiring more protected memory
        than parent will allow), then each child cgroup will get

  reply	other threads:[~2018-05-10 13:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-03 11:43 [PATCH v3 1/2] mm: introduce memory.min Roman Gushchin
2018-05-03 11:43 ` [PATCH v3 2/2] mm: ignore memory.min of abandoned memory cgroups Roman Gushchin
2018-05-03 17:38   ` Johannes Weiner
2018-05-09 18:07     ` Roman Gushchin
2018-05-09 22:38       ` Andrew Morton
2018-05-10 13:08         ` Roman Gushchin [this message]
2018-05-10 13:30 ` [PATCH v3 1/2] mm: introduce memory.min Michal Hocko
2018-05-10 14:04   ` Roman Gushchin

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=20180510130758.GA9129@castle.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=tj@kernel.org \
    --cc=vdavydov.dev@gmail.com \
    --subject='Re: [PATCH v3 2/2] mm: ignore memory.min of abandoned memory cgroups' \
    /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

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).