From patchwork Wed Apr 22 11:06:43 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yafang Shao X-Patchwork-Id: 11503515 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 E03A4159A for ; Wed, 22 Apr 2020 11:07:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ADB8B2077D for ; Wed, 22 Apr 2020 11:07:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nIPatHnR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ADB8B2077D 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 DB5478E000C; Wed, 22 Apr 2020 07:07:12 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id D653C8E0003; Wed, 22 Apr 2020 07:07:12 -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 C55B68E000C; Wed, 22 Apr 2020 07:07:12 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0223.hostedemail.com [216.40.44.223]) by kanga.kvack.org (Postfix) with ESMTP id AE6AA8E0003 for ; Wed, 22 Apr 2020 07:07:12 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 62E69181AEF10 for ; Wed, 22 Apr 2020 11:07:12 +0000 (UTC) X-FDA: 76735214304.02.snow31_5bfb45a24de38 X-Spam-Summary: 2,0,0,3d5f8848cda7f066,d41d8cd98f00b204,laoar.shao@gmail.com,,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1345:1437:1535:1543:1711:1730:1747:1777:1792:2393:2559:2562:2693:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:5007:6119:6261:6653:7514:7903:9413:10004:11026:11473:11658:11914:12043:12296:12297:12438:12517:12519:12555:12679:12895:14093:14096:14181:14394:14687:14721:21080:21444:21451:21627:21666:21795:21990:30012:30051:30054,0,RBL:209.85.210.193:@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: snow31_5bfb45a24de38 X-Filterd-Recvd-Size: 5706 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 11:07:11 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id b8so882337pfp.8 for ; Wed, 22 Apr 2020 04:07:11 -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=Oz+OiCwTvf7KFx0Sup3xjk+3/CvghxKKdZvc5peMgVU=; b=nIPatHnRd3qBqxFbWRimAwE3EwsQyo5GUkUyt3pfl3HnccbMp5EPZgdcZaNK2PcuHE wh/kR11GSPHgHDVQIY4guJqpxD1OdUGl0Wt881PHuYn7gbhecLne74O9mDXYIXy7MGOy 7qhoXC9irLtWOF8IWSZODR3VP1vf24i2tjJbMuSo2upVHY6qJ8lCAwkURhJm6yCWV2CG /1YBlZq5Y/QRSFakONPAj01AsJQFa6f8/QoFaHB90+SssjtO5oV6AUULZCZYKI4c63w4 17ghJxBmZtpsZgOpDIilWcUu9xuhovqiRMGSyxq3e0G5baFnLY8v1JUelscXIsaREYpc GdvQ== 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=Oz+OiCwTvf7KFx0Sup3xjk+3/CvghxKKdZvc5peMgVU=; b=qt0aS13THQiwxcP2cOvD2I4itR32udOqlLk21K7RJssba3mepGwcazVvZcvXSR2lO1 sqJiCRntougC2K0hT6FpukbQEm4CUsSaYQJMFLKPY9jHRgPKDsOPpIVb7c7Mcw4ctdQV K9vmLy1tm0cJfRUEQ/KKyufj1MW131Ulq4qiDvIExiZaS1H07DF2hTfzSU/Lx9LRiFqN Nj/DNNOfX3mm11Fxmgx4cl/EfRmGtZcMAc2sUt9Iog4NFN+2MSJ8l3iez/3YXPw2PH9p FFtidPOm1Bp0XaZnbWauqndz4fqjieWPglrHHqIkuu22Y6SQ/OcY1kkQJJ/WSBLdjeL1 jcvQ== X-Gm-Message-State: AGi0PuYtGCOzuRDtczHvmQfvrSTXg8ul/ln6LDEj2K75de6nuAPw+wpY h+pTvbRjJmIaZOoyp4JvTKUDE9m2tCI= X-Google-Smtp-Source: APiQypIHOEiidiJOeog1L6LXthJCk+gY1mVRjveqdfGF6rvTf/CLl3wgsL4MvRxXtJHSbZfhLvFgLg== X-Received: by 2002:a63:5717:: with SMTP id l23mr12541732pgb.217.1587553630967; Wed, 22 Apr 2020 04:07:10 -0700 (PDT) Received: from localhost.localdomain ([203.100.54.194]) by smtp.gmail.com with ESMTPSA id w125sm4902824pgw.22.2020.04.22.04.07.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2020 04:07:10 -0700 (PDT) From: Yafang Shao To: akpm@linux-foundation.org, mhocko@kernel.org Cc: linux-mm@kvack.org, Yafang Shao , Chris Down , Shakeel Butt , Johannes Weiner Subject: [PATCH v2] mm, memcg: fix inconsistent oom event behavior Date: Wed, 22 Apr 2020 07:06:43 -0400 Message-Id: <20200422110643.15725-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. Setting CGRP_ROOT_MEMORY_LOCAL_EVENTS for legacy hierarchy by default rather than special casing it somewhere quite deep in the code would be better, per discussion with Michal. Fixes: 9852ae3fe529 ("mm, memcg: consider subtrees in memory.events") Cc: Chris Down Cc: Shakeel Butt Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Yafang Shao Acked-by: Michal Hocko --- mm/memcontrol.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 5beea03dd58a..0f7381bddcee 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5940,10 +5940,20 @@ static void mem_cgroup_bind(struct cgroup_subsys_state *root_css) * guarantees that @root doesn't have any children, so turning it * on for the root memcg is enough. */ - if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) + if (cgroup_subsys_on_dfl(memory_cgrp_subsys)) { root_mem_cgroup->use_hierarchy = true; - else + } else { root_mem_cgroup->use_hierarchy = false; + /* + * Set CGRP_ROOT_MEMORY_LOCAL_EVENTS for legacy hierarchy + * by default to avoid inconsistent oom_kill behavior + * between root memcg and non-root memcg. + * Regarding default hierarchy, as this flag will be set + * or cleared later, we don't need to process it in this + * function. + */ + cgrp_dfl_root.flags |= CGRP_ROOT_MEMORY_LOCAL_EVENTS; + } } static int seq_puts_memcg_tunable(struct seq_file *m, unsigned long value)