From patchwork Fri Jan 22 18:43:41 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Johannes Weiner X-Patchwork-Id: 12040281 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E44FC433E0 for ; Fri, 22 Jan 2021 18:43:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B98FA23AC2 for ; Fri, 22 Jan 2021 18:43:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B98FA23AC2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 129486B0005; Fri, 22 Jan 2021 13:43:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FEEF6B0007; Fri, 22 Jan 2021 13:43:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE1816B0008; Fri, 22 Jan 2021 13:43:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id D91486B0005 for ; Fri, 22 Jan 2021 13:43:45 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 995512839 for ; Fri, 22 Jan 2021 18:43:45 +0000 (UTC) X-FDA: 77734284810.30.prose62_5f031152756e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 6641B18043161 for ; Fri, 22 Jan 2021 18:43:45 +0000 (UTC) X-HE-Tag: prose62_5f031152756e X-Filterd-Recvd-Size: 6806 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Jan 2021 18:43:44 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id x81so3260656qkb.0 for ; Fri, 22 Jan 2021 10:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=C9fNjhrnoyOFnHJ9WQ+/Ta+coPGgxGkP5OqAw7eb4FE=; b=jZfX+8gSvsMknjij2NXiIkewNvE/gS0U3cVGRcyPmCqSxmENCBZB94bg9qNEDpz1/6 EraLaqdwbEc4JCtd9r5PpiJZrDTX7sq3ubzrQkZDk37siT5lhYY+2d86mkxF/54wMn6I FFW2rpjqkRxx58b4cmvX5LghbDFYl6D9T1qiLQIrf9H0/Bm4zCQjT3lPd29XyUUTsyWW JErij86cT0276L6OHd2ics2wWE8glvLdLu7uHZiKNM6MBGiI+DCKpcAUKMGjRuiCo+tE 5IOV2/n++vOYBzOW3Dja7cVPBGgJKROdI78/O8suUL/c0aHEqbgDjxPMVcUaAYd1rEuH YIHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=C9fNjhrnoyOFnHJ9WQ+/Ta+coPGgxGkP5OqAw7eb4FE=; b=C6yRnSx75+YNzNy5qM1me1AQ0mgzYBJH/O+qn8bd13U1RCPw3ZJ4IDdyuxZIM5rnxZ mH2wjymUnkVR065/BDJr94UgCyJXfZApfPaHJh1ypPO8ldO8X1gT8RbIa9BRheZdrEUI HWqzckykVNzyB0+cKw2niPFUZX0HBBpqKL1jmI52Axw3SK7/5cJ3NN5pNraMDb5GJPy4 Hp5IhyNutOhCHEQv91psG/P/a1FLqJjx+i4MqIXp/tVtjpG3a8LtgMiq2GT+2+pGs26I vRPAbvH86rBpEwh9s8o+vFdHQn4hJhSl6dICx0XhcHmzOWVpA2eXAmDQdF383DoRSYLY SWOQ== X-Gm-Message-State: AOAM531+G4VRZet6yu9dOgUoWNfx4ApHEugg5N831catZBMitvnWpsI+ RidS9Irgm1kxJOzhI/aJF9FcIg== X-Google-Smtp-Source: ABdhPJxPINKbhhsKe9/jTOjmTNsgfz8lXr+DTPt12mOvOHrzFu8u8RyYYax30EeJNoeW4KXB6egXuA== X-Received: by 2002:a05:620a:205a:: with SMTP id d26mr2334943qka.288.1611341023991; Fri, 22 Jan 2021 10:43:43 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:589b]) by smtp.gmail.com with ESMTPSA id l204sm6940425qke.56.2021.01.22.10.43.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jan 2021 10:43:42 -0800 (PST) From: Johannes Weiner To: Andrew Morton Cc: Roman Gushchin , Michal Hocko , Shakeel Butt , =?utf-8?q?Michal_Koutn=C3=BD?= , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: [PATCH] Revert "mm: memcontrol: avoid workload stalls when lowering memory.high" Date: Fri, 22 Jan 2021 13:43:41 -0500 Message-Id: <20210122184341.292461-1-hannes@cmpxchg.org> X-Mailer: git-send-email 2.30.0 MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This reverts commit 536d3bf261a2fc3b05b3e91e7eef7383443015cf, as it can cause writers to memory.high to get stuck in the kernel forever, performing page reclaim and consuming excessive amounts of CPU cycles. Before the patch, a write to memory.high would first put the new limit in place for the workload, and then reclaim the requested delta. After the patch, the kernel tries to reclaim the delta before putting the new limit into place, in order to not overwhelm the workload with a sudden, large excess over the limit. However, if reclaim is actively racing with new allocations from the uncurbed workload, it can keep the write() working inside the kernel indefinitely. This is causing problems in Facebook production. A privileged system-level daemon that adjusts memory.high for various workloads running on a host can get unexpectedly stuck in the kernel and essentially turn into a sort of involuntary kswapd for one of the workloads. We've observed that daemon busy-spin in a write() for minutes at a time, neglecting its other duties on the system, and expending privileged system resources on behalf of a workload. To remedy this, we have first considered changing the reclaim logic to break out after a couple of loops - whether the workload has converged to the new limit or not - and bound the write() call this way. However, the root cause that inspired the sequence change in the first place has been fixed through other means, and so a revert back to the proven limit-setting sequence, also used by memory.max, is preferable. The sequence was changed to avoid extreme latencies in the workload when the limit was lowered: the sudden, large excess created by the limit lowering would erroneously trigger the penalty sleeping code that is meant to throttle excessive growth from below. Allocating threads could end up sleeping long after the write() had already reclaimed the delta for which they were being punished. However, erroneous throttling also caused problems in other scenarios at around the same time. This resulted in commit b3ff92916af3 ("mm, memcg: reclaim more aggressively before high allocator throttling"), included in the same release as the offending commit. When allocating threads now encounter large excess caused by a racing write() to memory.high, instead of entering punitive sleeps, they will simply be tasked with helping reclaim down the excess, and will be held no longer than it takes to accomplish that. This is in line with regular limit enforcement - i.e. if the workload allocates up against or over an otherwise unchanged limit from below. With the patch breaking userspace, and the root cause addressed by other means already, revert it again. Fixes: 536d3bf261a2 ("mm: memcontrol: avoid workload stalls when lowering memory.high") Cc: # 5.8+ Reported-by: Tejun Heo Signed-off-by: Johannes Weiner Acked-by: Roman Gushchin Reviewed-by: Shakeel Butt Acked-by: Michal Hocko Acked-by: Chris Down --- mm/memcontrol.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Andrew, this is a replacement for mm-memcontrol-prevent-starvation-when-writing-memoryhigh.patch diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 605f671203ef..a8611a62bafd 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6273,6 +6273,8 @@ 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; @@ -6296,10 +6298,7 @@ static ssize_t memory_high_write(struct kernfs_open_file *of, break; } - page_counter_set_high(&memcg->memory, high); - memcg_wb_domain_size_changed(memcg); - return nbytes; }