linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Shakeel Butt <shakeelb@google.com>, <linux-mm@kvack.org>,
	<kernel-team@fb.com>, <linux-kernel@vger.kernel.org>,
	Roman Gushchin <guro@fb.com>, Domas Mituzas <domas@fb.com>,
	Tejun Heo <tj@kernel.org>, Chris Down <chris@chrisdown.name>
Subject: [PATCH] mm: memcontrol: avoid workload stalls when lowering memory.high
Date: Thu, 9 Jul 2020 12:47:18 -0700	[thread overview]
Message-ID: <20200709194718.189231-1-guro@fb.com> (raw)

Memory.high limit is implemented in a way such that the kernel
penalizes all threads which are allocating a memory over the limit.
Forcing all threads into the synchronous reclaim and adding some
artificial delays allows to slow down the memory consumption and
potentially give some time for userspace oom handlers/resource control
agents to react.

It works nicely if the memory usage is hitting the limit from below,
however it works sub-optimal if a user adjusts memory.high to a value
way below the current memory usage. It basically forces all workload
threads (doing any memory allocations) into the synchronous reclaim
and sleep. This makes the workload completely unresponsive for
a long period of time and can also lead to a system-wide contention on
lru locks. It can happen even if the workload is not actually tight on
memory and has, for example, a ton of cold pagecache.

In the current implementation writing to memory.high causes an atomic
update of page counter's high value followed by an attempt to reclaim
enough memory to fit into the new limit. To fix the problem described
above, all we need is to change the order of execution: try to push
the memory usage under the limit first, and only then set the new
high limit.

Signed-off-by: Roman Gushchin <guro@fb.com>
Reported-by: Domas Mituzas <domas@fb.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Chris Down <chris@chrisdown.name>
---
 mm/memcontrol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b8424aa56e14..4b71feee7c42 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6203,8 +6203,6 @@ static ssize_t memory_high_write(struct kernfs_open_file *of,
 	if (err)
 		return err;
 
-	page_counter_set_high(&memcg->memory, high);
-
 	for (;;) {
 		unsigned long nr_pages = page_counter_read(&memcg->memory);
 		unsigned long reclaimed;
@@ -6228,6 +6226,8 @@ static ssize_t memory_high_write(struct kernfs_open_file *of,
 			break;
 	}
 
+	page_counter_set_high(&memcg->memory, high);
+
 	return nbytes;
 }
 
-- 
2.26.2



             reply	other threads:[~2020-07-09 19:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 19:47 Roman Gushchin [this message]
2020-07-10 12:29 ` [PATCH] mm: memcontrol: avoid workload stalls when lowering memory.high Michal Hocko
2020-07-10 14:12   ` Shakeel Butt
2020-07-10 18:42     ` Roman Gushchin
2020-07-10 19:19       ` Shakeel Butt
2020-07-10 19:41         ` Roman Gushchin
2020-07-14  8:41         ` Michal Hocko
2020-07-14 15:32           ` Shakeel Butt
2020-07-14 15:50             ` Michal Hocko
2020-07-14 15:38         ` Johannes Weiner
2020-07-14 17:06           ` Shakeel Butt
2020-07-15 16:54             ` Johannes Weiner

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=20200709194718.189231-1-guro@fb.com \
    --to=guro@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chrisdown.name \
    --cc=domas@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=shakeelb@google.com \
    --cc=tj@kernel.org \
    /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).