From patchwork Sat May 2 14:10:55 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11523921 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 2F8EF92A for ; Sat, 2 May 2020 14:11:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFD0324953 for ; Sat, 2 May 2020 14:11:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D1j+08h3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFD0324953 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 12E8C8E0005; Sat, 2 May 2020 10:11:16 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 0E0AB8E0001; Sat, 2 May 2020 10:11:16 -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 F372B8E0005; Sat, 2 May 2020 10:11:15 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0245.hostedemail.com [216.40.44.245]) by kanga.kvack.org (Postfix) with ESMTP id DA5B28E0001 for ; Sat, 2 May 2020 10:11:15 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 999828248D52 for ; Sat, 2 May 2020 14:11:15 +0000 (UTC) X-FDA: 76771966110.21.range94_62448a51ab040 X-Spam-Summary: 2,0,0,19a886d673530817,d41d8cd98f00b204,laoar.shao@gmail.com,,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1345:1437:1535:1542:1711:1730:1747:1777:1792:2393:2559:2562:2693:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3874:4321:5007:6119:6261:6653:7514:7903:9413:10004:11026:11473:11658:11914:12043:12296:12297:12438:12517:12519:12555:12679:12895:14093:14181:14394:14687:14721:21080:21444:21451:21627:21666:21795:30051:30054,0,RBL:209.85.214.194:@gmail.com:.lbl8.mailshell.net-66.100.201.100 62.50.0.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:26,LUA_SUMMARY:none X-HE-Tag: range94_62448a51ab040 X-Filterd-Recvd-Size: 5024 Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Sat, 2 May 2020 14:11:15 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id f15so4791634plr.3 for ; Sat, 02 May 2020 07:11:15 -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; bh=YlyT5EVhQOzQaF+9as445LHAbo2iNjUcRXscx+aU6fQ=; b=D1j+08h3KS29Yau6mCMwCFoM9wUQBSc+fMSLOR1q6+dEBgXPNwXbw7u/CyWFQudPQP UaZYLnYeLWeFuMCxN3h6CX7wwMtXyDgrv+UYCN7FsM5bW5ZeNx3/zH+UrivkNXiN2cph xKVXXI3Spssg5BMfiFLrapzweO5b8VfVUVADyXHxHjDKz3A4K2sxV01Jdk5w+3f9wMvf 7/Km8+nOFsXlUgIKSv3lR8Xg9BIX+zYv8xEVxI69Q+bQSgw9B1ZtPVRQAs23s4aDfg5l Fwk+/wLKPrNadxviUXPmX2wB7nP3Yv6FO2N6+f0x98OGdDeFibrukvQux1optjPoHJPf xu1g== 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; bh=YlyT5EVhQOzQaF+9as445LHAbo2iNjUcRXscx+aU6fQ=; b=jrsOVRjR6lkxV1vmHma8E4Fx3AMGwJli1d5SRYlcbYl29CzrUKDXpldCNh/h8JNLXh zkbSyeSGeD7sHiO/KzJrTQpkol22KuKhtGW96G3QMSfCpdz79mc+l87pWzFp/hwpLeoF ZDaTulSiCFg2/FHcGtXkT8sq7stJjUqS/K2AfBsPnTgUnigDz6aGcwuY8FEiWK//05oq 8qnn40ZkbZF4GBf3Nqd7n0Od7xajdfalq4aV0coHbQxVmYxxK7eS4PeB3U9N7Pwsb6uO 1z78Hd0SX3fwK7abCR1nE/TK/LIXAHckxWKdyxtaYQQv9uu8HPCMblyT3uugWE9QtgeB o/pg== X-Gm-Message-State: AGi0PuY3dXbpkSv6cG1U4vdc+KBwHZCPKgYKF4xIYe7GZTHdq90qP+14 ST0KO9GXlvqFrAhYNE+I7og= X-Google-Smtp-Source: APiQypJf5zU5zeVP2mmEWRqDhC8GU0uRnyOtYWAX5kXc8DTAG+Tri8/IDzi/CRdx+YRi2ZXb91fjsA== X-Received: by 2002:a17:90a:8a14:: with SMTP id w20mr6165399pjn.176.1588428674277; Sat, 02 May 2020 07:11:14 -0700 (PDT) Received: from localhost.localdomain ([203.100.54.194]) by smtp.gmail.com with ESMTPSA id a23sm4610791pfo.145.2020.05.02.07.11.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 02 May 2020 07:11:13 -0700 (PDT) From: Yafang Shao To: akpm@linux-foundation.org Cc: linux-mm@kvack.org, Yafang Shao , Chris Down , Michal Hocko , Johannes Weiner Subject: [PATCH resend] mm, memcg: fix inconsistent oom event behavior Date: Sat, 2 May 2020 10:10:55 -0400 Message-Id: <20200502141055.7378-1-laoar.shao@gmail.com> X-Mailer: git-send-email 2.18.1 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: A recent commit 9852ae3fe529 ("mm, memcg: consider subtrees in memory.events") changes the behavior of memcg events, which will consider subtrees in memory.events. But oom_kill event is a special one as it is used in both cgroup1 and cgroup2. In cgroup1, it is displayed in memory.oom_control. The file memory.oom_control is in both root memcg and non root memcg, that is different with memory.event as it only in non-root memcg. That commit is okay for cgroup2, but it is not okay for cgroup1 as it will cause inconsistent behavior between root memcg and non-root memcg. Here's an example on why this behavior is inconsistent in cgroup1. root memcg / memcg foo / memcg bar Suppose there's an oom_kill in memcg bar, then the oon_kill will be root memcg : memory.oom_control(oom_kill) 0 / memcg foo : memory.oom_control(oom_kill) 1 / memcg bar : memory.oom_control(oom_kill) 1 For the non-root memcg, its memory.oom_control(oom_kill) includes its descendants' oom_kill, but for root memcg, it doesn't include its descendants' oom_kill. That means, memory.oom_control(oom_kill) has different meanings in different memcgs. That is inconsistent. Then the user has to know whether the memcg is root or not. If we can't fully support it in cgroup1, for example by adding memory.events.local into cgroup1 as well, then let's don't touch its original behavior. Fixes: 9852ae3fe529 ("mm, memcg: consider subtrees in memory.events") Reviewed-by: Shakeel Butt Cc: Chris Down Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Yafang Shao Acked-by: Johannes Weiner Acked-by: Chris Down Acked-by: Michal Hocko --- include/linux/memcontrol.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index d275c72c4f8e..977edd3b7bd8 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -783,6 +783,8 @@ static inline void memcg_memory_event(struct mem_cgroup *memcg, atomic_long_inc(&memcg->memory_events[event]); cgroup_file_notify(&memcg->events_file); + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) + break; if (cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_LOCAL_EVENTS) break; } while ((memcg = parent_mem_cgroup(memcg)) &&