From patchwork Sun Jan 24 05:01:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12042055 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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_RED 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 2498CC433DB for ; Sun, 24 Jan 2021 05:01:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8BDF22CB3 for ; Sun, 24 Jan 2021 05:01:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8BDF22CB3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6AAEC6B000E; Sun, 24 Jan 2021 00:01:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 658686B0010; Sun, 24 Jan 2021 00:01:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5213A6B0012; Sun, 24 Jan 2021 00:01:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 363BE6B000E for ; Sun, 24 Jan 2021 00:01:24 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id F17031EE6 for ; Sun, 24 Jan 2021 05:01:23 +0000 (UTC) X-FDA: 77739470046.16.bee35_6300c532757a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id CB4A6100E690C for ; Sun, 24 Jan 2021 05:01:23 +0000 (UTC) X-HE-Tag: bee35_6300c532757a X-Filterd-Recvd-Size: 3783 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Sun, 24 Jan 2021 05:01:23 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5F7E422581; Sun, 24 Jan 2021 05:01:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1611464482; bh=WIzIzn9J3HEweHSPZO07FXCJBKhAfp8duZ1IMwbU0dA=; h=Date:From:To:Subject:In-Reply-To:From; b=BTZ3GkSQ/l7aIpN+UsV1arwdMpxsOn2KXVMDLeXyczecPkoZWWDWS2+wf6A3qJk+7 LAuYI0Es+Nri4TAUDjQ+J6b6mBc5zNWfppGLvJjvPhjbpW0oSiaf9jsuU9dtUUKomz uPi7oDeMJ9p1GHQ2f1Gkruvp4MsWZYBa20WNFC5o= Date: Sat, 23 Jan 2021 21:01:19 -0800 From: Andrew Morton To: akpm@linux-foundation.org, guro@fb.com, hannes@cmpxchg.org, linux-mm@kvack.org, mhocko@suse.com, mkoutny@suse.com, mm-commits@vger.kernel.org, shakeelb@google.com, stable@vger.kernel.org, tj@kernel.org, torvalds@linux-foundation.org Subject: [patch 06/19] mm: memcontrol: prevent starvation when writing memory.high Message-ID: <20210124050119.34lm1Gw1Q%akpm@linux-foundation.org> In-Reply-To: <20210123210029.a7c704d0cab204683e41ad10@linux-foundation.org> User-Agent: s-nail v14.8.16 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: From: Johannes Weiner Subject: mm: memcontrol: prevent starvation when writing memory.high When a value is written to a cgroup's memory.high control file, the write() context first tries to reclaim the cgroup to size before putting the limit in place for the workload. Concurrent charges from the workload can keep such a write() looping in reclaim indefinitely. In the past, a write to memory.high would first put the limit in place for the workload, then do targeted reclaim until the new limit has been met - similar to how we do it for memory.max. This wasn't prone to the described starvation issue. However, this sequence could cause excessive latencies in the workload, when allocating threads could be put into long penalty sleeps on the sudden memory.high overage created by the write(), before that had a chance to work it off. Now that memory_high_write() performs reclaim before enforcing the new limit, reflect that the cgroup may well fail to converge due to concurrent workload activity. Bail out of the loop after a few tries. Link: https://lkml.kernel.org/r/20210112163011.127833-1-hannes@cmpxchg.org Fixes: 536d3bf261a2 ("mm: memcontrol: avoid workload stalls when lowering memory.high") Signed-off-by: Johannes Weiner Reviewed-by: Shakeel Butt Reported-by: Tejun Heo Acked-by: Roman Gushchin Reviewed-by: Michal Koutný Cc: Michal Hocko Cc: [5.8+] Signed-off-by: Andrew Morton --- mm/memcontrol.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/mm/memcontrol.c~mm-memcontrol-prevent-starvation-when-writing-memoryhigh +++ a/mm/memcontrol.c @@ -6273,7 +6273,6 @@ static ssize_t memory_high_write(struct for (;;) { unsigned long nr_pages = page_counter_read(&memcg->memory); - unsigned long reclaimed; if (nr_pages <= high) break; @@ -6287,10 +6286,10 @@ static ssize_t memory_high_write(struct continue; } - reclaimed = try_to_free_mem_cgroup_pages(memcg, nr_pages - high, - GFP_KERNEL, true); + try_to_free_mem_cgroup_pages(memcg, nr_pages - high, + GFP_KERNEL, true); - if (!reclaimed && !nr_retries--) + if (!nr_retries--) break; }