From patchwork Mon May 4 04:26:21 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11524967 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 EF58C17E8 for ; Mon, 4 May 2020 04:26:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BC51620757 for ; Mon, 4 May 2020 04:26:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bicGSkaX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC51620757 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F121A8E0007; Mon, 4 May 2020 00:26:51 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id EC1858E0001; Mon, 4 May 2020 00: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 DB0448E0007; Mon, 4 May 2020 00:26:51 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id C467C8E0001 for ; Mon, 4 May 2020 00:26:51 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 907818249980 for ; Mon, 4 May 2020 04:26:51 +0000 (UTC) X-FDA: 76777751022.30.tramp90_3bd97a5d75208 X-Spam-Summary: 2,0,0,80c90b0e187a95cd,d41d8cd98f00b204,laoar.shao@gmail.com,,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1345:1359:1437:1535:1542:1711:1730:1747:1777:1792:2393:2559:2562:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:4250:4321:5007:6119:6120:6261:6653:7514:7901:7903:9413:10004:11026:11473:11658:11914:12043:12050:12296:12297:12517:12519:12555:12895:13180:13229:14181:14394:14687:14721:21080:21324:21444:21451:21611:21627:21666:21740:30046:30054:30064,0,RBL:209.85.214.196:@gmail.com:.lbl8.mailshell.net-62.50.0.100 66.100.201.100,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:25,LUA_SUMMARY:none X-HE-Tag: tramp90_3bd97a5d75208 X-Filterd-Recvd-Size: 5077 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 04:26:51 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id u22so6295980plq.12 for ; Sun, 03 May 2020 21:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=fVWtUjOUApdXkRnNhxOexL1wsSeAV1kQtINnrlYuC98=; b=bicGSkaX3QEyGk2Gq/NpCiq0sQFgEWYieLT707Ymb02RMO8j2lqKZ+5CSoTJ1Msii6 11d5KhQxwcwoQ1FjTECxZqTKLKx2wNIgDxSkpqR9Pz+fB0946lF4mJnrEYUOnTtLSnAW hvRqpN2E/ovvT/2cVz+q0G5mQ1UOxrLieoKzmrxRDUZA9CT6eGNJoaTlY2PPEKxpfDaK NtiolAHhrkZ/nlaG3yNVyD+WMg8CPfBLgs8wmB1GnBDWG+scjVjEWLTj0lGXeyOQvTNE r4IX1wntC+Zcouqz+dBYz6FdZtU/1+hNmoVxEtcTYiDT/b8ic1BV/uZKIi+LEbWEYl95 EBOQ== 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:in-reply-to :references; bh=fVWtUjOUApdXkRnNhxOexL1wsSeAV1kQtINnrlYuC98=; b=XQpI1WQPGqaS2okyby2EUmOa/MR1pM/OyqAzmlHiEya/P2evwUTuE7By1xmgYvyizx xO+kJB+RZhpuKh/LwZziaJrzCMhrzJL9+6MDHjYvj67uNGhY6eTKvd1mUIvQFvsC0z+C gaE25UvwFguTo1Wa/q8mbeLclD39NpRprTa29J0FFoMd5Qg5khH29J7SvLNNWA+mfkb1 4JmIvn9L8ySEeh4oykU6NA/aITQn9hNXWFt1CoFcFy50XkPOfSn65z9yic/MCLU5SFyD C5qYG2PdGjj60vNud0HUs0yvwkkTSmomIh5EKTD35x6barfIaobxGwgnbew1akuLnsta cx4A== X-Gm-Message-State: AGi0PuY/vfyU1OfliUx2bp0KHzEQXT2wZacumfel93jH4hOo8XBk4r/v nmnOK6l3NJKkqn3bj/soo8Q= X-Google-Smtp-Source: APiQypJPxc3MEzM+mhfNsR7AOqVfopAxbB+xTulcBBuT1VQ7W3RjyaiH5mqXLTIZYl4ioCM2ChuTgQ== X-Received: by 2002:a17:902:8a81:: with SMTP id p1mr8670524plo.104.1588566410215; Sun, 03 May 2020 21:26:50 -0700 (PDT) Received: from localhost.localdomain ([203.100.54.194]) by smtp.gmail.com with ESMTPSA id y8sm8012878pfg.216.2020.05.03.21.26.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2020 21:26:49 -0700 (PDT) From: Yafang Shao To: akpm@linux-foundation.org, shakeelb@google.com Cc: hannes@cmpxchg.org, mhocko@kernel.org, guro@fb.com, gthelen@google.com, linux-mm@kvack.org, Yafang Shao Subject: [PATCH v2 2/2] mm, memcg: don't try to kill a process if memcg is not populated Date: Mon, 4 May 2020 00:26:21 -0400 Message-Id: <20200504042621.10334-3-laoar.shao@gmail.com> X-Mailer: git-send-email 2.18.1 In-Reply-To: <20200504042621.10334-1-laoar.shao@gmail.com> References: <20200504042621.10334-1-laoar.shao@gmail.com> 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: Recently Shakeel reported a issue which also confused me several months earlier. Bellow is his report - Lowering memory.max can trigger an oom-kill if the reclaim does not succeed. However if oom-killer does not find a process for killing, it dumps a lot of warnings. Deleting a memcg does not reclaim memory from it and the memory can linger till there is a memory pressure. One normal way to proactively reclaim such memory is to set memory.max to 0 just before deleting the memcg. However if some of the memcg's memory is pinned by others, this operation can trigger an oom-kill without any process and thus can log a lot of un-needed warnings. So, ignore all such warnings from memory.max. A better way to avoid this issue is to avoid trying to kill a process if memcg is not populated. Note that OOM is different from OOM kill. OOM is a status that the system or memcg is out of memory, while OOM kill is a result that a process inside this memcg is killed when this memcg is in OOM status. That is the same reason why there're both MEMCG_OOM event and MEMCG_OOM_KILL event. If we have already known that there's nothing to kill, i.e. the memcg is not populated, then we don't need a try. Basically why setting memory.max to 0 is better than setting memory.high to 0 before deletion. The reason is remote charging. High reclaim does not work for remote memcg and the usage can go till max or global pressure. [shakeelb@google.com: improve commit log] Signed-off-by: Yafang Shao Reviewed-by: Shakeel Butt Cc: Johannes Weiner Cc: Michal Hocko Cc: Roman Gushchin Cc: Greg Thelen --- mm/memcontrol.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 985edce98491..29afe3df9d98 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6102,6 +6102,10 @@ static ssize_t memory_max_write(struct kernfs_open_file *of, } memcg_memory_event(memcg, MEMCG_OOM); + + if (!cgroup_is_populated(memcg->css.cgroup)) + break; + if (!mem_cgroup_oom_kill(memcg, GFP_KERNEL, 0)) break; }