From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE229C47247 for ; Thu, 30 Apr 2020 19:31:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 917D720656 for ; Thu, 30 Apr 2020 19:31:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="H7PU8veV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 917D720656 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 46AA18E0006; Thu, 30 Apr 2020 15:31:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 41C6C8E0001; Thu, 30 Apr 2020 15:31:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 331AD8E0006; Thu, 30 Apr 2020 15:31:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id 1948C8E0001 for ; Thu, 30 Apr 2020 15:31:48 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D23E38248D51 for ; Thu, 30 Apr 2020 19:31:47 +0000 (UTC) X-FDA: 76765516254.11.low77_fa6d05c85950 X-HE-Tag: low77_fa6d05c85950 X-Filterd-Recvd-Size: 6837 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Apr 2020 19:31:47 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id l11so2218410lfc.5 for ; Thu, 30 Apr 2020 12:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cpNuhLG27M2LY+OOiLxKTk8CvH0axJBvq+gwTXFPBUw=; b=H7PU8veVNF+gc5hrBF2gDUfDMOVuiQ465ISM3u5O9VOlsXrR95GB0x08wFhDWOEG8d LMhX3dmPirJkEZf6LCI8kLisP5w0SesJa7YUTb2Jy4oizvDR/2f+kwoa1UGQ+tgllXv5 rpRXjfhU5HUxOBwREgWybDRSXv3MDbdYnILoNZ7InA5Gwy7NMCiw0yUQvTcCzpwhdVgq S6GXQKKzziEhSL3ltV/MksxJBz2Dvyak7tZTx+s3Tolw5HqsgAoseH2NVGDTibNmEZ5w +UquDn6daGjrVzFocqQSgiQ8+dDTf4FKgYOOWmd5oszy6er0CJ3vQaow6En/aaXYbEcJ pusA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cpNuhLG27M2LY+OOiLxKTk8CvH0axJBvq+gwTXFPBUw=; b=CQD+eWWdXgg69zw82JU3Lg+stjyDXFzQRSOF0PMSCBDiimjDmj1WkBR5Cf88NQSU2h NiF2CzScJI0E3Pq63SBqNUAaj6NEwfemlRmov7WcCKI6Y2Tz3cikFxaIwh9nKZcluG7B 2rkyePSRaEO21DptyhSzsvsGmSKpcmOQRK/fHiAo0Se95i2QvUM4fYS93GQtzQctt4BZ RjgLwjdgH8u6+mzBggh4yDzLjC6xlMopy96safacEsMBofvs1h/VMG4C/HZRUzDQhXGm LdVeQUqYfgs3Gkctmybib3CUL/Z6x72lS6v5sAp5S1wGccN+RdC2sHrbe1c+HZIjKEK4 DMhg== X-Gm-Message-State: AGi0PuYBZHyXf+KG9oZwtC0m/yYc7EocAv/wL6nKf3aNP0Cm8gyMao+H if6LCTMxEaLUd+8075vmtQuSHuFjGiXbE31aHbd/7g== X-Google-Smtp-Source: APiQypJ/2ALFHyQQbXJQTtf9kYNFCkkm+177kv0LkXgl8aL1VWKHvEh5rbHJmHJlkQIJTUSmxKnzQi37hH2FPRkWI3w= X-Received: by 2002:ac2:5e65:: with SMTP id a5mr110232lfr.189.1588275105505; Thu, 30 Apr 2020 12:31:45 -0700 (PDT) MIME-Version: 1.0 References: <20200430182712.237526-1-shakeelb@google.com> <20200430190610.GD339283@carbon.dhcp.thefacebook.com> In-Reply-To: <20200430190610.GD339283@carbon.dhcp.thefacebook.com> From: Shakeel Butt Date: Thu, 30 Apr 2020 12:31:32 -0700 Message-ID: Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Greg Thelen , Andrew Morton , Linux MM , Cgroups , LKML Content-Type: text/plain; charset="UTF-8" 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: On Thu, Apr 30, 2020 at 12:06 PM Roman Gushchin wrote: > > Hello, Shakeel! > > On Thu, Apr 30, 2020 at 11:27:12AM -0700, Shakeel Butt wrote: > > 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. > > Makes total sense to me. > > > > > 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 un-needed warnings. So, ignore all such warnings from memory.max. > > > > Signed-off-by: Shakeel Butt > > --- > > include/linux/oom.h | 3 +++ > > mm/memcontrol.c | 9 +++++---- > > mm/oom_kill.c | 2 +- > > 3 files changed, 9 insertions(+), 5 deletions(-) > > > > diff --git a/include/linux/oom.h b/include/linux/oom.h > > index c696c265f019..6345dc55df64 100644 > > --- a/include/linux/oom.h > > +++ b/include/linux/oom.h > > @@ -52,6 +52,9 @@ struct oom_control { > > > > /* Used to print the constraint info. */ > > enum oom_constraint constraint; > > + > > + /* Do not warn even if there is no process to be killed. */ > > + bool no_warn; > > I'd invert it to warn. Or maybe even warn_on_no_proc? > Sure. > > }; > > > > extern struct mutex oom_lock; > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 317dbbaac603..a1f00d9b9bb0 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -1571,7 +1571,7 @@ unsigned long mem_cgroup_size(struct mem_cgroup *memcg) > > } > > > > static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, > > - int order) > > + int order, bool no_warn) > > { > > struct oom_control oc = { > > .zonelist = NULL, > > @@ -1579,6 +1579,7 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, > > .memcg = memcg, > > .gfp_mask = gfp_mask, > > .order = order, > > + .no_warn = no_warn, > > }; > > bool ret; > > > > @@ -1821,7 +1822,7 @@ static enum oom_status mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int > > mem_cgroup_oom_notify(memcg); > > > > mem_cgroup_unmark_under_oom(memcg); > > - if (mem_cgroup_out_of_memory(memcg, mask, order)) > > + if (mem_cgroup_out_of_memory(memcg, mask, order, false)) > > ret = OOM_SUCCESS; > > else > > ret = OOM_FAILED; > > @@ -1880,7 +1881,7 @@ bool mem_cgroup_oom_synchronize(bool handle) > > mem_cgroup_unmark_under_oom(memcg); > > finish_wait(&memcg_oom_waitq, &owait.wait); > > mem_cgroup_out_of_memory(memcg, current->memcg_oom_gfp_mask, > > - current->memcg_oom_order); > > + current->memcg_oom_order, false); > > } else { > > schedule(); > > mem_cgroup_unmark_under_oom(memcg); > > @@ -6106,7 +6107,7 @@ static ssize_t memory_max_write(struct kernfs_open_file *of, > > } > > > > memcg_memory_event(memcg, MEMCG_OOM); > > - if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0)) > > + if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0, true)) > > I wonder if we can handle it automatically from the oom_killer side? > We can suppress warnings if oc->memcg is set and the cgroup scanning > showed that there are no belonging processes? > What about the charging path? Do we not want such warnings from charging paths? It might be due to some misconfiguration.