All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: akpm@linux-foundation.org, mhocko@kernel.org,
	vdavydov.dev@gmail.com, linux-mm@kvack.org,
	Chris Down <chris@chrisdown.name>, Roman Gushchin <guro@fb.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm, memcg: fix wrong mem cgroup protection
Date: Fri, 24 Apr 2020 09:44:38 -0400	[thread overview]
Message-ID: <20200424134438.GA496852@cmpxchg.org> (raw)
In-Reply-To: <20200424131450.GA495720@cmpxchg.org>

On Fri, Apr 24, 2020 at 09:14:52AM -0400, Johannes Weiner wrote:
> However, mem_cgroup_protected() never expected anybody to look at the
> effective protection values when it indicated that the cgroup is above
> its protection. As a result, a query during limit reclaim may return
> stale protection values that were calculated by a previous reclaim
> cycle in which the cgroup did have siblings.

Btw, I think there is opportunity to make this a bit less error prone.

We have a mem_cgroup_protected() that returns yes or no, essentially,
but protection isn't a binary state anymore.

It's also been a bit iffy that it looks like a simple predicate
function, but it indeed needs to run procedurally for each cgroup in
order for the calculations throughout the tree to be correct.

It might be better to have a

	mem_cgroup_calculate_protection()

that runs for every cgroup we visit and sets up the internal state;
then have more self-explanatory query functions on top of that:

	mem_cgroup_below_min()
	mem_cgroup_below_low()
	mem_cgroup_protection()

What do you guys think?

diff --git a/mm/vmscan.c b/mm/vmscan.c
index e0f502b5fca6..dbd3f75d39b9 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2615,14 +2615,15 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
 		unsigned long reclaimed;
 		unsigned long scanned;
 
-		switch (mem_cgroup_protected(target_memcg, memcg)) {
-		case MEMCG_PROT_MIN:
+		mem_cgroup_calculate_protection(target_memcg, memcg);
+
+		if (mem_cgroup_below_min(memcg)) {
 			/*
 			 * Hard protection.
 			 * If there is no reclaimable memory, OOM.
 			 */
 			continue;
-		case MEMCG_PROT_LOW:
+		} else if (mem_cgroup_below_low(memcg)) {
 			/*
 			 * Soft protection.
 			 * Respect the protection only as long as
@@ -2634,16 +2635,6 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
 				continue;
 			}
 			memcg_memory_event(memcg, MEMCG_LOW);
-			break;
-		case MEMCG_PROT_NONE:
-			/*
-			 * All protection thresholds breached. We may
-			 * still choose to vary the scan pressure
-			 * applied based on by how much the cgroup in
-			 * question has exceeded its protection
-			 * thresholds (see get_scan_count).
-			 */
-			break;
 		}
 
 		reclaimed = sc->nr_reclaimed;

  reply	other threads:[~2020-04-24 13:44 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23  6:16 [PATCH] mm, memcg: fix wrong mem cgroup protection Yafang Shao
2020-04-23 15:33 ` Chris Down
2020-04-23 21:13   ` Roman Gushchin
2020-04-24  0:32     ` Yafang Shao
2020-04-24  0:32       ` Yafang Shao
2020-04-24 10:40     ` Michal Hocko
2020-04-24 10:57       ` Yafang Shao
2020-04-24 10:57         ` Yafang Shao
2020-04-24  0:49   ` Yafang Shao
2020-04-24  0:49     ` Yafang Shao
2020-04-24 12:18     ` Chris Down
2020-04-24 12:44       ` Yafang Shao
2020-04-24 12:44         ` Yafang Shao
2020-04-24 13:05         ` Chris Down
2020-04-24 13:10           ` Yafang Shao
2020-04-24 13:10             ` Yafang Shao
2020-04-23 21:06 ` Roman Gushchin
2020-04-24  0:29   ` Yafang Shao
2020-04-24  0:29     ` Yafang Shao
2020-04-24 13:14 ` Johannes Weiner
2020-04-24 13:44   ` Johannes Weiner [this message]
2020-04-24 14:33     ` Michal Hocko
2020-04-24 16:08     ` Yafang Shao
2020-04-24 16:08       ` Yafang Shao
2020-04-24 14:29   ` Michal Hocko
2020-04-24 15:10     ` Johannes Weiner
2020-04-24 16:21       ` Michal Hocko
2020-04-24 16:51         ` Johannes Weiner
2020-04-27  8:25           ` Michal Hocko
2020-04-27  8:37             ` Yafang Shao
2020-04-27  8:37               ` Yafang Shao
2020-04-27 16:52             ` Johannes Weiner
2020-04-24 16:21     ` Roman Gushchin
2020-04-24 16:30       ` Yafang Shao
2020-04-24 16:30         ` Yafang Shao
2020-04-24 16:00   ` Yafang Shao
2020-04-24 16:00     ` Yafang Shao

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=20200424134438.GA496852@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chrisdown.name \
    --cc=guro@fb.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vdavydov.dev@gmail.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.