linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeelb@google.com>
To: Rik van Riel <riel@surriel.com>
Cc: lsf-pc@lists.linux-foundation.org, Linux MM <linux-mm@kvack.org>,
	 Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Roman Gushchin <guro@fb.com>
Subject: Re: [LSF/MM TOPIC] Proactive Memory Reclaim
Date: Tue, 23 Apr 2019 10:04:19 -0700	[thread overview]
Message-ID: <CALvZod44yAJTLuvg9jtqHF9uKuKNtXL9p_=3Ld+eakSijAbo1A@mail.gmail.com> (raw)
In-Reply-To: <8588314f167c9525e134ade91afdbebcd9e62eb1.camel@surriel.com>

On Tue, Apr 23, 2019 at 9:08 AM Rik van Riel <riel@surriel.com> wrote:
>
> On Tue, 2019-04-23 at 08:30 -0700, Shakeel Butt wrote:
>
> > Topic: Proactive Memory Reclaim
> >
> > Motivation/Problem: Memory overcommit is most commonly used technique
> > to reduce the cost of memory by large infrastructure owners. However
> > memory overcommit can adversely impact the performance of latency
> > sensitive applications by triggering direct memory reclaim. Direct
> > reclaim is unpredictable and disastrous for latency sensitive
> > applications.
>
> This sounds similar to a project Johannes has
> been working on, except he is not tracking which
> memory is idle at all, but only the pressure on
> each cgroup, through the PSI interface:
>
> https://facebookmicrosites.github.io/psi/docs/overview
>

I think both techniques are orthogonal and can be used concurrently.
This technique proactively reclaims memory and hopes that we don't go
to direct reclaim but in the worst case if we trigger direct reclaim
then we can use PSI to early detect when to give up on reclaim and
trigger oom-kill.

Another thing I want to point out is our usage model: this proactive
memory reclaim is transparent to the jobs. The admin (infrastructure
owner) is using proactive reclaim to create more schedulable memory
transparently to the job owners.

> Discussing the pros and cons, and experiences with
> both approaches seems like a useful topic. I'll add
> it to the agenda.
>

Thanks a lot.
Shakeel


  reply	other threads:[~2019-04-23 17:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 15:30 Shakeel Butt
2019-04-23 15:58 ` Mel Gorman
2019-04-23 16:33   ` Shakeel Butt
2019-04-23 16:49     ` Yang Shi
2019-04-23 17:12       ` Shakeel Butt
2019-04-23 18:26         ` Yang Shi
2019-04-23 16:08 ` Rik van Riel
2019-04-23 17:04   ` Shakeel Butt [this message]
2019-04-23 17:49     ` Johannes Weiner
2019-04-23 17:34   ` Suren Baghdasaryan
2019-04-23 17:31 ` Johannes Weiner
2019-04-24 16:28   ` Christopher Lameter

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='CALvZod44yAJTLuvg9jtqHF9uKuKNtXL9p_=3Ld+eakSijAbo1A@mail.gmail.com' \
    --to=shakeelb@google.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mhocko@kernel.org \
    --cc=riel@surriel.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