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=-7.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 8F7ADC3A5A9 for ; Mon, 4 May 2020 06:56:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2649820746 for ; Mon, 4 May 2020 06:56:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2649820746 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AF7148E0005; Mon, 4 May 2020 02:56:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA6568E0001; Mon, 4 May 2020 02:56:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BD6C8E0005; Mon, 4 May 2020 02:56:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 87A028E0001 for ; Mon, 4 May 2020 02:56:03 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 495C81785D for ; Mon, 4 May 2020 06:56:03 +0000 (UTC) X-FDA: 76778127006.17.food84_34d367ebcc441 X-HE-Tag: food84_34d367ebcc441 X-Filterd-Recvd-Size: 6513 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 06:56:02 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id k1so19530207wrx.4 for ; Sun, 03 May 2020 23:56:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jog4tz7JjzUtRGEMAhpCFp/8qoFX9sXC3gjVWFz42K8=; b=Y76Bqa4WLZ4NcksmlEqepKRjOr6O7Xf86brShQZSTsqNcFh8rk0gUSswB84HTwUC97 rpHvsi7l3NsGH2pXS90rnbieDrjvrLv9btrr0DVXNOLbNY8HhIGZgIFxjfjBrbvXCWVV 6UnNuX+s5kAZlUH/5iwxtmwL7RsyV2bVXJqgETSe+Dk1XZs23g2H56babMNzOy8Eqk1l Pjeh7ZNsrwlBQbV5+71bAxYK6I34auZTHs6NMdknknvmLTgoLtLHWqE9bt2ov0uIo3Ia HbPcVPhWIJrku1YKxdjsMaWDZFu/A32msiyoB966NKNBMkKdd1YeIf2ezDzIFA/3n/ZG vnCQ== X-Gm-Message-State: AGi0PubxyED8yYrheXfzJHP33Uqf3kPGyBZ2r2P/a3AW3qf8n0kRceBo XpeDKscoXheuUDThWteyBWQ= X-Google-Smtp-Source: APiQypLjsOFQcdZkPtXf6gINBNzvhzc1hULS1DgGyhiSHP0rM4ORDVqfjQGSrKudO5a5FtWC9ZkFaw== X-Received: by 2002:adf:f641:: with SMTP id x1mr17292876wrp.151.1588575361670; Sun, 03 May 2020 23:56:01 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id e2sm17031153wrv.89.2020.05.03.23.56.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2020 23:56:01 -0700 (PDT) Date: Mon, 4 May 2020 08:56:00 +0200 From: Michal Hocko To: Shakeel Butt Cc: Johannes Weiner , Roman Gushchin , Greg Thelen , Andrew Morton , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max Message-ID: <20200504065600.GA22838@dhcp22.suse.cz> References: <20200430182712.237526-1-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200430182712.237526-1-shakeelb@google.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: On Thu 30-04-20 11:27:12, 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. It shouldn't dump much more than the regular OOM report AFAICS. Sure there is "Out of memory and no killable processes..." message printed as well but is that a real problem? > 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. OK, I can see why you might want to use memory.max for that purpose but I do not really understand why the oom report is a problem here. memory.max can trigger the oom kill and user should be expecting the oom report under that condition. Why is "no eligible task" so special? Is it because you know that there won't be any tasks for your particular case? What about other use cases where memory.max is not used as a "sweep before tear down"? > 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; > }; > > 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)) > break; > } > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 463b3d74a64a..5ace39f6fe1e 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -1098,7 +1098,7 @@ bool out_of_memory(struct oom_control *oc) > > select_bad_process(oc); > /* Found nothing?!?! */ > - if (!oc->chosen) { > + if (!oc->chosen && !oc->no_warn) { > dump_header(oc, NULL); > pr_warn("Out of memory and no killable processes...\n"); > /* > -- > 2.26.2.526.g744177e7f7-goog -- Michal Hocko SUSE Labs