linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Michal Hocko <mhocko@kernel.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>
Cc: 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 14:16:02 -0800	[thread overview]
Message-ID: <36e127fe-814e-9b22-cb7d-73a2e3daf2aa@linux.intel.com> (raw)
In-Reply-To: <20200220161915.GI20509@dhcp22.suse.cz>

On 2/20/20 8:19 AM, Michal Hocko wrote:

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

Thanks for the explanation.  I wonder if a few factors could mitigate the
stalls in the tiered memory context:

1. The speed of demotion between top tier memory and second tier memory
is much faster than reclaiming the pages and swapping them out.

2. Demotion targets pages that are colder and less active.

3. If we engage the page demotion mostly in the background, say via kswapd,
and not in the direct reclaim path, we can avoid long stalls
during page allocation.  If the memory pressure is severe
on the top tier memory, perhaps the memory could be allocated from the second
tier memory node to avoid stalling.

The stalls could still prove to be problematic.  We're implementing
prototypes and we'll have a better ideas on workload latencies once we can collect data.

Tim



  reply	other threads:[~2020-02-20 22:16 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
2020-02-20 22:16       ` Tim Chen [this message]
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=36e127fe-814e-9b22-cb7d-73a2e3daf2aa@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --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=mhocko@kernel.org \
    --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).