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 D4E6BC3A5A9 for ; Mon, 4 May 2020 08:18:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F9F5206B9 for ; Mon, 4 May 2020 08:18:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F9F5206B9 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 27BF38E0005; Mon, 4 May 2020 04:18:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 22B828E0003; Mon, 4 May 2020 04:18:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 142158E0005; Mon, 4 May 2020 04:18:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id EDB088E0003 for ; Mon, 4 May 2020 04:18:51 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AD8E8180AD83B for ; Mon, 4 May 2020 08:18:51 +0000 (UTC) X-FDA: 76778335662.03.cream80_303bba41fb638 X-HE-Tag: cream80_303bba41fb638 X-Filterd-Recvd-Size: 5522 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 08:18:51 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id e16so14681878wra.7 for ; Mon, 04 May 2020 01:18:51 -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=Wo8uOKSOD0kJvMykxHdnwQMT51xUSUgy+a0Z6CnxAYQ=; b=EvLOuyFQhle4zjNCfJTRkY0UxP5c6q0hYU5eB8U8r+wcyh4EKIeIwlfkt/GKt3vuwV GRvKO8xJ5oE8GtUZ5a1YTGxFhWKQI1RB6vRumUB5vrVWMoGBHuVUPKb8FDkn5RamWYTa eJ3EdtwqV4Uj9dEQCGXYsIX3fc39yRrTGZQW2cOLbSxcGJSfZ3e+WRzx7hGdAxuOAxtc WmFCO9leXrOAPQ34w8rCWb4iGcdn0FoQySrdPj1Oq0jUlD6wyRluF1QdmkN1feqNNwBQ sF+9CS97D//W7mbnXxo6t0pApFNN9ZZSFb7kPcmKrhnZZF8ErI5dmG90LL3z4O4kSNKF wn4g== X-Gm-Message-State: AGi0Pua7KFxUP/h323aP/2hJLM+F3A8coh23d1EkT2ZhhYJB67sFdS4a bAPkoDtrH5+9ZB0msZ4HHsQ= X-Google-Smtp-Source: APiQypKko0gyN9uplkVHKayeEu/NqfSCfQw9J2MfqEWjkfFBj8iKz87L6+5azSNcTF2S/vivGtnklA== X-Received: by 2002:adf:fcc6:: with SMTP id f6mr16052015wrs.388.1588580330424; Mon, 04 May 2020 01:18:50 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id y3sm927981wrt.87.2020.05.04.01.18.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 01:18:49 -0700 (PDT) Date: Mon, 4 May 2020 10:18:48 +0200 From: Michal Hocko To: Yafang Shao Cc: akpm@linux-foundation.org, shakeelb@google.com, hannes@cmpxchg.org, guro@fb.com, gthelen@google.com, linux-mm@kvack.org Subject: Re: [PATCH v2 2/2] mm, memcg: don't try to kill a process if memcg is not populated Message-ID: <20200504081848.GJ22838@dhcp22.suse.cz> References: <20200504042621.10334-1-laoar.shao@gmail.com> <20200504042621.10334-3-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504042621.10334-3-laoar.shao@gmail.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: [It would be really great if a newer version was posted only after there was a wider consensus on the approach.] On Mon 04-05-20 00:26:21, Yafang Shao wrote: > Recently Shakeel reported a issue which also confused me several months > earlier. Bellow is his report - > 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. > 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 of un-needed warnings. So, ignore all such warnings from memory.max. > > A better way to avoid this issue is to avoid trying to kill a process if > memcg is not populated. > Note that OOM is different from OOM kill. OOM is a status that the > system or memcg is out of memory, while OOM kill is a result that a > process inside this memcg is killed when this memcg is in OOM status. Agreed. > That is the same reason why there're both MEMCG_OOM event and > MEMCG_OOM_KILL event. If we have already known that there's nothing to > kill, i.e. the memcg is not populated, then we don't need a try. OK, but you are not explaining why a silent failure is really better than no oom report under oom situation. With your patch, there is no failure reported to the user and there is also no sign that there might be a problem that memcg leaves memory behind that is not bound to any (killable) process. This could be an important information. Besides that I really do not see any actual problem that this would be fixing. Reducing the hard limit is an operation which might trigger the oom killer and leave an oom report behind. Having an OOM without any tasks is pretty much a corner case and making it silent just makes it harder to debug. > Basically why setting memory.max to 0 is better than setting memory.high to > 0 before deletion. The reason is remote charging. High reclaim does not > work for remote memcg and the usage can go till max or global pressure. > > [shakeelb@google.com: improve commit log] > Signed-off-by: Yafang Shao > Reviewed-by: Shakeel Butt > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Roman Gushchin > Cc: Greg Thelen > --- > mm/memcontrol.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 985edce98491..29afe3df9d98 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -6102,6 +6102,10 @@ static ssize_t memory_max_write(struct kernfs_open_file *of, > } > > memcg_memory_event(memcg, MEMCG_OOM); > + > + if (!cgroup_is_populated(memcg->css.cgroup)) > + break; > + > if (!mem_cgroup_oom_kill(memcg, GFP_KERNEL, 0)) > break; > } > -- > 2.18.2 -- Michal Hocko SUSE Labs