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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C3BD1C3A5A9 for ; Mon, 4 May 2020 14:53:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E49C20721 for ; Mon, 4 May 2020 14:53:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QVr6XQdC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E49C20721 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 E9B428E0027; Mon, 4 May 2020 10:53:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E71E38E0024; Mon, 4 May 2020 10:53:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D87BA8E0027; Mon, 4 May 2020 10:53:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id C05C78E0024 for ; Mon, 4 May 2020 10:53:14 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 89D4A180AD80F for ; Mon, 4 May 2020 14:53:14 +0000 (UTC) X-FDA: 76779329508.20.hour96_90afb4e0cd83f X-HE-Tag: hour96_90afb4e0cd83f X-Filterd-Recvd-Size: 6229 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 14:53:14 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id 188so9984657lfa.10 for ; Mon, 04 May 2020 07:53:14 -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=PWZ26t9Z32MlW5UKTGmfXwCpHufQN5g8ypGnGhMoTV4=; b=QVr6XQdCtnmAtOuVNcvlC8Q1NmED36YsFG+qbvUri4BnTHMhK1Vs1D87apQIG3FCOW QOrtlGCTNDtbWPZopaxb0X/P/XDjsTPZYshG4GDHuQRJq2oELxlYiSQNonoapjawLKHI k4zgc06E0LPchPMixyKmgFmuR7lufFcUr2XeSWpcn3TUNyEDjMO217tthRxiept1lNWN IwTLEODOGj1uNTUGZkJM9r+Ch3yOv2M5whFChG1zwovMr5qbJoVor+OVfpaAhX64v34I Bl6XQFAQWRBet5kGBbSGtoyRG52+whbAV+8X4TeiQxgoow5TnXNzG2UL4E6IlyvEnHyu 7K1w== 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=PWZ26t9Z32MlW5UKTGmfXwCpHufQN5g8ypGnGhMoTV4=; b=Ks8B92L5JlRrIjK867ehcV9aW5YNzOzGgM2f2OdkrNWf2BijrS+WHY1lDXcgVQmr3n kcEPzElc4ljd3Z27qyucFMT4pUHXGGBcy2QyZ8gY3tjAzFrI3nVC/Iy+yjKgjxBpXiFh RI5m+DHAwI/0wyRmxradId+xEnnWN7gq1Kt9RZ2ZIlwUVtPFjwf6E9SHM3H9YNB72Glb N5DpzOdajqrF0Ve9gvA4/QjWyp8XusaKXRWYFg5Uk7LLfRmWAquYwnSlpqNQ8f23gjye TK2rm7erLY1BsKB4oM+ybGid/JgW+Ad1+vGZ1SMeGcDEu6eNq0bTNDKuryYBKhV25FLf /awA== X-Gm-Message-State: AGi0PuZAYlzddeC+t1l2lyTJYJM5T9fM/FfqXl0DrjTALQ4fcHwiu6ux 5DzPZq3MNSctIzZV8/Xh5uGQzOYK2Vx1Mfeo/Li5PQ== X-Google-Smtp-Source: APiQypIhrhGrNgrw3phbw7oshVoOFP13vW6aP5Kr4CW7NqXozPGxi60oaOXj6CS4/G7IL7lprTdlDDydkK2ahudmrIc= X-Received: by 2002:ac2:5e65:: with SMTP id a5mr11921180lfr.189.1588603992481; Mon, 04 May 2020 07:53:12 -0700 (PDT) MIME-Version: 1.0 References: <20200430182712.237526-1-shakeelb@google.com> <20200504065600.GA22838@dhcp22.suse.cz> <20200504141136.GR22838@dhcp22.suse.cz> In-Reply-To: <20200504141136.GR22838@dhcp22.suse.cz> From: Shakeel Butt Date: Mon, 4 May 2020 07:53:01 -0700 Message-ID: Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , 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 Mon, May 4, 2020 at 7:11 AM Michal Hocko wrote: > > On Mon 04-05-20 06:54:40, Shakeel Butt wrote: > > On Sun, May 3, 2020 at 11:56 PM Michal Hocko wrote: > > > > > > 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. > > > > It may not be a problem for an individual or small scale deployment > > but when "sweep before tear down" is the part of the workflow for > > thousands of machines cycling through hundreds of thousands of cgroups > > then we can potentially flood the logs with not useful dumps and may > > hide (or overflow) any useful information in the logs. > > If you are doing this in a large scale and the oom report is really a > problem then you shouldn't be resetting hard limit to 0 in the first > place. > I think I have pretty clearly described why we want to reset the hard limit to 0, so, unless there is an alternative I don't see why we should not be doing this. > > > 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"? > > > > What other such use-cases would be? The only use-case I can envision > > of adjusting limits dynamically of a live cgroup are resource > > managers. However for cgroup v2, memory.high is the recommended way to > > limit the usage, so, why would resource managers be changing > > memory.max instead of memory.high? I am not sure. What do you think? > > There are different reasons to use the hard limit. Mostly to contain > potential runaways. While high limit might be a sufficient measure to > achieve that as well the hard limit is the last resort. And it clearly > has the oom killer semantic so I am not really sure why you are > comparing the two. > I am trying to see if "no eligible task" is really an issue and should be warned for the "other use cases". The only real use-case I can think of are resource managers adjusting the limit dynamically. I don't see "no eligible task" a concerning reason for such use-case. If you have some other use-case please do tell. Shakeel