From patchwork Tue Apr 14 01:59:52 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11486519 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 427B86CA for ; Tue, 14 Apr 2020 02:00:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0AE8420732 for ; Tue, 14 Apr 2020 02:00:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="naRICs6t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0AE8420732 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 C6ED88E0003; Mon, 13 Apr 2020 22:00:08 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id C1F0F8E0001; Mon, 13 Apr 2020 22:00:08 -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 B34828E0003; Mon, 13 Apr 2020 22:00:08 -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 98C588E0001 for ; Mon, 13 Apr 2020 22:00:08 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 52F7752BF for ; Tue, 14 Apr 2020 02:00:08 +0000 (UTC) X-FDA: 76704805296.14.town19_5877036e5692f X-Spam-Summary: 2,0,0,69c9e8ba9091f0a3,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:12048: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.216.67:@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:25,LUA_SUMMARY:none X-HE-Tag: town19_5877036e5692f X-Filterd-Recvd-Size: 5191 Received: from mail-pj1-f67.google.com (mail-pj1-f67.google.com [209.85.216.67]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 02:00:07 +0000 (UTC) Received: by mail-pj1-f67.google.com with SMTP id mn19so4581647pjb.0 for ; Mon, 13 Apr 2020 19:00:07 -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=jioPbgVo9Yj4CEfIRDyGfI7olAR404zuuwj5DU8a6S4=; b=naRICs6tMO6+WIKTe7Ons2paw6UBSb4LdcNdrI/d+kTWuuycOKOPYv2fuFqdTH3rW9 WM94EfazlRNSg/dj+NjhNldXzxg3HUSs2+/GosK9qtJkFzWrrCfsKTKvPf7j9s7IvGOj vXZ2Y3437zLOdiANxDgcOh7/UwJnnZOKdGre6Cw02aPflfwJyXnVeCcUhbOd0GkMHi4K dafjueOQSuWcfF+FWI2WYSadCNQ4gOjsdyOYdjiHsKYdwklqROSfTT12lprrI0pSZFmp bobLm1ZbY0irdZNyFv6sINdlNUL3nEOvFyvKb3GDOlIqsqJslVxNwjnyqwR2c0pG8MZL pCpQ== 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=jioPbgVo9Yj4CEfIRDyGfI7olAR404zuuwj5DU8a6S4=; b=WLwLRamPL/vVUcfAPgUBBdvjkgCN8jYQbVueOxXspeKAUiIv1EMA6N37klvQrcUucx G6LI6hbVEQvJZEVtg4YmztVzDUH+TJu5MeB3H2ghb/7PzcXkQIHEk4n11J5bLo0wXmrz ITrhdCQhQJZ3TUlS1UAwxGWsB1utZVSUAyCfbWZ5ALWdkpF4womDpG5dLyUM3yeVecCC JeWFZ2Esb+9s/9pfLMwV5fYXEIg8dX6diCjAk3cNv/ap7voOTNzRCTjibMAfSAiatQ95 US6Lyg6VwFxwdAyhZxUUyGuzw18K8k6xsovq8w4iliW76PqY+T50LYpuW/+RbL0R6Op8 pvcA== X-Gm-Message-State: AGi0PuYU6hHhDn3MhLJJle1VhwG7vQq3VmICXI+MGBqc8UWLHUMeWafG ngBbcHxqGXqe3JPNIiVPxME= X-Google-Smtp-Source: APiQypLJzTcMq383lhPvI/c4rqgqPjiU3o5IrIj0BOxlMdOGRS6muNQ2z+5gT7A3Y+povs0vMyaGEg== X-Received: by 2002:a17:90b:2355:: with SMTP id ms21mr14031489pjb.163.1586829606806; Mon, 13 Apr 2020 19:00:06 -0700 (PDT) Received: from localhost.localdomain ([203.100.54.194]) by smtp.gmail.com with ESMTPSA id y126sm4496835pgy.91.2020.04.13.19.00.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2020 19:00:05 -0700 (PDT) From: Yafang Shao To: shakeelb@google.com, chris@chrisdown.name, hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org Cc: linux-mm@kvack.org, Yafang Shao , stable@vger.kernel.org Subject: [PATCH v2] mm, memcg: fix inconsistent oom event behavior Date: Mon, 13 Apr 2020 21:59:52 -0400 Message-Id: <20200414015952.3590-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. So let's recover the original behavior for cgroup1. Fixes: 9852ae3fe529 ("mm, memcg: consider subtrees in memory.events") Cc: Chris Down Cc: Johannes Weiner Cc: stable@vger.kernel.org Reviewed-by: Shakeel Butt Signed-off-by: Yafang Shao --- include/linux/memcontrol.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 8c340e6b347f..a0ae080a67d1 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -798,7 +798,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 (cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_LOCAL_EVENTS) + if (cgrp_dfl_root.flags & CGRP_ROOT_MEMORY_LOCAL_EVENTS || + !cgroup_subsys_on_dfl(memory_cgrp_subsys)) break; } while ((memcg = parent_mem_cgroup(memcg)) && !mem_cgroup_is_root(memcg));