All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: teawater <teawaterz@linux.alibaba.com>
Cc: hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com,
	akpm@linux-foundation.org, guro@fb.com, shakeelb@google.com,
	Yang Shi <yang.shi@linux.alibaba.com>,
	tj@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org,
	cgroups@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: vmscan: memcg: Add global shrink priority
Date: Thu, 19 Dec 2019 11:26:18 +0000	[thread overview]
Message-ID: <20191219112618.GA72828@chrisdown.name> (raw)
In-Reply-To: <25AA9500-B249-42C2-B162-2B8D4EE83BB0@linux.alibaba.com>

Hi Hui,

teawater writes:
>Memory.min, low, high can affect the global shrink behavior.  They can help 
>task keep some pages to help protect performance.
>
>But what I want is the low priority tasks (the tasks that performance is not 
>very important) do more shrink first.  And when low priority tasks doesn’t 
>have enough pages to be dropped and system need more free page, shrink the 
>high priority task’s pages.  Because at this time, system’s stable is more 
>important than the performance of priority task.
>With memory.min and memory.low, I have no idea to config them to support this.  
>That is why I add global shrink priority.

For sure, that's what I'm suggesting you use memory.{min,low} for -- you define 
some subset of the cgroup hierarchy as "protected", and then you bias reclaim 
away from protected cgroups (and thus *towards* unprotected cgroups) by biasing 
the size of LRU scanning. See my patch that went into 5.4 and the examples in 
the commit message:

     commit 9783aa9917f8ae24759e67bf882f1aba32fe4ea1
     Author: Chris Down <chris@chrisdown.name>
     Date:   Sun Oct 6 17:58:32 2019 -0700

         mm, memcg: proportional memory.{low,min} reclaim

You can see how we're using memory.{low,min} to achieve this in this case 
study[0]. It's not exactly equivalent technically to your solution, but the end 
goals are similar.

Thanks,

Chris

0: https://facebookmicrosites.github.io/cgroup2/docs/overview.html#case-study-the-fbtax2-project

  reply	other threads:[~2019-12-19 11:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18  9:42 [PATCH] mm: vmscan: memcg: Add global shrink priority Hui Zhu
2019-12-18 10:47 ` Yafang Shao
2019-12-19  9:04   ` teawater
2019-12-18 14:09 ` Chris Down
2019-12-19  8:59   ` teawater
2019-12-19 11:26     ` Chris Down [this message]
2019-12-20  7:48       ` teawater
2019-12-29 13:38       ` teawater
2019-12-29 14:02         ` Chris Down
2019-12-30  3:32           ` teawater

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=20191219112618.GA72828@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=shakeelb@google.com \
    --cc=teawaterz@linux.alibaba.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vdavydov.dev@gmail.com \
    --cc=yang.shi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.