linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Tim Chen <tim.c.chen@linux.intel.com>,
	lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	Dave Hansen <dave.hansen@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Huang Ying <ying.huang@intel.com>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Memory cgroups, whether you like it or not
Date: Thu, 20 Feb 2020 17:19:15 +0100	[thread overview]
Message-ID: <20200220161915.GI20509@dhcp22.suse.cz> (raw)
In-Reply-To: <20200220160604.ak33n3hrqouyiuyv@box>

On Thu 20-02-20 19:06:04, Kirill A. Shutemov wrote:
> On Fri, Feb 14, 2020 at 11:45:41AM +0100, Michal Hocko wrote:
> > On Wed 05-02-20 10:34:57, Tim Chen wrote:
> > > There is existing infrastructure for memory soft limit per cgroup we
> > > can leverage to implement such a scheme.  We'll like to find out if this
> > > approach makes sense for people working on systems with multiple memory tiers.
> > 
> > Soft limit is dead.
> 
> Michal, could you remind what the deal with soft limit? Why is it dead?

because of the very disruptive semantic. Essentially the way how it was
grafted into the normal reclaim. It is essentially a priority 0 reclaim
round to shrink a hierarchy which is the most in excess before we do a
normal reclaim. This can lead to an over reclaim, long stalls etc.

There were a lot of discussions on that matter on the mailing list few
years back. We have tried to make the semantic more reasonable but
failed on that and the result is a new cgroup v2 interface essentially.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2020-02-20 16:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-05 18:34 [LSF/MM TOPIC] Memory cgroups, whether you like it or not Tim Chen
2020-02-14 10:45 ` [Lsf-pc] " Michal Hocko
2020-02-20 16:06   ` Kirill A. Shutemov
2020-02-20 16:19     ` Michal Hocko [this message]
2020-02-20 22:16       ` Tim Chen
2020-02-21  8:42         ` Michal Hocko
2020-03-04 20:52   ` Tim Chen

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=20200220161915.GI20509@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=ying.huang@intel.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).