From patchwork Tue Apr 28 18:26:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Down X-Patchwork-Id: 11515359 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 72D1081 for ; Tue, 28 Apr 2020 18:26:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 40B9E21D80 for ; Tue, 28 Apr 2020 18:26:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="FIUW+caX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40B9E21D80 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6A36E8E0006; Tue, 28 Apr 2020 14:26:51 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 653978E0001; Tue, 28 Apr 2020 14:26:51 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56A2B8E0006; Tue, 28 Apr 2020 14:26:51 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 41F988E0001 for ; Tue, 28 Apr 2020 14:26:51 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 09CF44DD6 for ; Tue, 28 Apr 2020 18:26:51 +0000 (UTC) X-FDA: 76758095022.02.ghost09_3bc15ce349428 X-Spam-Summary: 2,0,0,ced9d4edb3b9a1e1,d41d8cd98f00b204,chris@chrisdown.name,,RULES_HIT:41:355:379:800:960:973:988:989:1260:1277:1312:1313:1314:1345:1359:1437:1516:1518:1519:1535:1542:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2553:2559:2562:2897:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:4250:5007:6261:6653:7514:7576:7903:9163:10004:10400:10450:10455:11026:11473:11658:11914:12043:12295:12296:12297:12438:12517:12519:12555:12664:12679:12895:13161:13229:13255:13439:13895:14096:14097:14181:14394:14721:19904:19999:21080:21444:21451:21627:21740:21939:21990:30012:30054:30056:30064:30070:30090,0,RBL:209.85.221.65:@chrisdown.name:.lbl8.mailshell.net-62.2.0.100 66.100.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:68,LUA_SUMMARY:none X-HE-Tag: ghost09_3bc15ce349428 X-Filterd-Recvd-Size: 5629 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 18:26:50 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id g13so25848314wrb.8 for ; Tue, 28 Apr 2020 11:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8ZdOelXqdALp+t5GpXOOCmyCgx7RbdhWdYql4OpbI1c=; b=FIUW+caXr+iJxtL6SRGRKizlkX7XhzWQuOY05F0+5+5/65k+s+9ywMQwaLpbod1SvJ FfDh3SAdEhODgckqhW2bHwjVwebnbxOH1HsAcAe4T3Fd/1U0rACWccleZh2AdKLIkD+h o/RxBNRzbhY/2DUlNUpR3LbBF56ufvPXeDgfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8ZdOelXqdALp+t5GpXOOCmyCgx7RbdhWdYql4OpbI1c=; b=QQQHvMJcrac9NPfP6A/AvCyNeH+SCjKJCyDgTDs5eQUg1mggOZbbQec9ZqA2SHRkyP 2cboZpJ6VL52HZzGNfhJqLFo1oiM6M3ZIMr5XsGvRqaruYWuE2OOFaqzVGbWsieku69X B+My9sGeXdjrtMV4bM8AxZ+uEg7fPCO3BWlxInC0CQLvvk5jwS5tCwfZTFMTac5xTdj2 ppOhYT6KaS7VbwC8YW2vp9pa/wGo7aS3MvYyI2gUDTeWnxH6YTCtEJIDX7tvKrC3cRd7 48jU8ZOU/4U+8FpG1D63yhswyZsolI0fvfK6BtR4+CuPXY8iRXeqGUmhpMxPoOjLRKWB qkQQ== X-Gm-Message-State: AGi0PublfaxxkIJtRLHBgx3SEIcTBDHVjjT069TPAx7HrSjcEhe2yeKa sUN13SeVbUn8N41zPa4BwTOcuw== X-Google-Smtp-Source: APiQypJ2+N7o09gAo7QjMQFnU2CwELzmpsGz8p6QbSTx74nuWdjD7zRh7ERIHa4tuyomWgoTtmqg7Q== X-Received: by 2002:a5d:490f:: with SMTP id x15mr33086688wrq.37.1588098408915; Tue, 28 Apr 2020 11:26:48 -0700 (PDT) Received: from localhost ([2a01:4b00:8432:8a00:56e1:adff:fe3f:49ed]) by smtp.gmail.com with ESMTPSA id r17sm25942192wrn.43.2020.04.28.11.26.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 11:26:48 -0700 (PDT) Date: Tue, 28 Apr 2020 19:26:47 +0100 From: Chris Down To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Yafang Shao , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] mm, memcg: Avoid stale protection values when cgroup is above protection Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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: Yafang Shao A cgroup can have both memory protection and a memory limit to isolate it from its siblings in both directions - for example, to prevent it from being shrunk below 2G under high pressure from outside, but also from growing beyond 4G under low pressure. Commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") implemented proportional scan pressure so that multiple siblings in excess of their protection settings don't get reclaimed equally but instead in accordance to their unprotected portion. During limit reclaim, this proportionality shouldn't apply of course: there is no competition, all pressure is from within the cgroup and should be applied as such. Reclaim should operate at full efficiency. 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. When this happens, reclaim is unnecessarily hesitant and potentially slow to meet the desired limit. In theory this could lead to premature OOM kills, although it's not obvious this has occurred in practice. Fixes: 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim") Signed-off-by: Yafang Shao Signed-off-by: Chris Down Cc: Johannes Weiner Cc: Michal Hocko Cc: Roman Gushchin [hannes@cmpxchg.org: rework code comment] [hannes@cmpxchg.org: changelog] [chris@chrisdown.name: fix store tear] [chris@chrisdown.name: retitle] Acked-by: Johannes Weiner Acked-by: Roman Gushchin Signed-off-by: Yafang Shao Signed-off-by: Michal Hocko Acked-by: Roman Gushchin --- mm/memcontrol.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 0be00826b832..b0374be44e9e 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6392,8 +6392,19 @@ enum mem_cgroup_protection mem_cgroup_protected(struct mem_cgroup *root, if (!root) root = root_mem_cgroup; - if (memcg == root) + if (memcg == root) { + /* + * The cgroup is the reclaim root in this reclaim + * cycle, and therefore not protected. But it may have + * stale effective protection values from previous + * cycles in which it was not the reclaim root - for + * example, global reclaim followed by limit reclaim. + * Reset these values for mem_cgroup_protection(). + */ + WRITE_ONCE(memcg->memory.emin, 0); + WRITE_ONCE(memcg->memory.elow, 0); return MEMCG_PROT_NONE; + } usage = page_counter_read(&memcg->memory); if (!usage)