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=-4.0 required=3.0 tests=INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 ADCB1C3A5A9 for ; Mon, 4 May 2020 07:03:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 75A0420757 for ; Mon, 4 May 2020 07:03:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 75A0420757 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 0DE9F8E0005; Mon, 4 May 2020 03:03:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08FD58E0001; Mon, 4 May 2020 03:03:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBFE08E0005; Mon, 4 May 2020 03:03:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id D364E8E0001 for ; Mon, 4 May 2020 03:03:04 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 946DE82499A8 for ; Mon, 4 May 2020 07:03:04 +0000 (UTC) X-FDA: 76778144688.18.plant86_7223e2f00444d X-HE-Tag: plant86_7223e2f00444d X-Filterd-Recvd-Size: 4053 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 07:03:04 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id x17so19540029wrt.5 for ; Mon, 04 May 2020 00:03:04 -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=jjVK3IGY3lofxgky6MANKIlS/RTE1msGdHN8C79gtRA=; b=jjsSHG1oAxYv4gZ8AvyjynX73NgMRMJWAIuJNQ+KcJ0iTKKd98F2mLofZcbLqP5W9r DHveVzRvK/VQeTWMCHn1NuzlkktSwMg0nApRqOLx50sYTVh8E+oZyb+1i0yQBIrNsCR4 4r5dYX8m7oeUJcfNdCSHUMEY5MFUUPtd8hcnlMxNnM/ZrB1p6adToip355C8hbv1MyRH P/k3Df3dzmqWs9l2BbIp7foRYSerzpLVuHNp36iPIFJb4+hdZoqwaHyNZuoziGWsr8Rp qQmJQecbD87c6j8H2Ajg0O2cmNnDhXjBSuLeewwTCBMMypqCcwKqIEJwNmo6YIzJr5J0 Y1kA== X-Gm-Message-State: AGi0PuaHeAWWpRW+79Tk1FlIEtpULHs78mx7/3HwutLoLDKrCfEDSshh Q1e1apoYTqS71L2T8ujjMdk= X-Google-Smtp-Source: APiQypL1DoXx6w0TGJSBvgI/zBJ2RIwW2P/T7NsRocZrPXDloYOn7lqwJM5NQOxDkI/4wpi4dbdQkg== X-Received: by 2002:adf:f40b:: with SMTP id g11mr18764892wro.178.1588575783322; Mon, 04 May 2020 00:03:03 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id r3sm18434951wrx.72.2020.05.04.00.03.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 May 2020 00:03:02 -0700 (PDT) Date: Mon, 4 May 2020 09:03:01 +0200 From: Michal Hocko To: Yafang Shao Cc: Shakeel Butt , Johannes Weiner , Roman Gushchin , Greg Thelen , Andrew Morton , Linux MM , Cgroups , LKML Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max Message-ID: <20200504070301.GC22838@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: 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 Fri 01-05-20 09:39:24, Yafang Shao wrote: > On Fri, May 1, 2020 at 2:27 AM 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. > > > > I have been confused by this behavior for several months and I think > it will confuse more memcg users. Could you be more specific what has caused the confusion? > We should keep the memcg oom behavior consistent with system oom - no > oom kill if no process. This is not the global mmemcg behavior. We do complain loud on no eligible tasks and actually panic the system. Memcg cannot simply do the same by default for obvious reasons. > What about bellow change ? > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index e28098e13f1c..25fbc37a747f 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -6086,6 +6086,9 @@ static ssize_t memory_max_write(struct > kernfs_open_file *of, > continue; > } > > + if (!cgroup_is_populated(memcg->css.cgroup)) > + break; > + > memcg_memory_event(memcg, MEMCG_OOM); > if (!mem_cgroup_out_of_memory(memcg, GFP_KERNEL, 0)) > break; I am not a great fan to be honest. The warning might be useful for other usecases when it is not clear that the memcg is empty. -- Michal Hocko SUSE Labs