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 C23BBC3A5A9 for ; Mon, 4 May 2020 19:24:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8712620707 for ; Mon, 4 May 2020 19:24:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GbV667a2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8712620707 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 1E8938E0078; Mon, 4 May 2020 15:24:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 198158E0058; Mon, 4 May 2020 15:24:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AE828E0078; Mon, 4 May 2020 15:24:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0083.hostedemail.com [216.40.44.83]) by kanga.kvack.org (Postfix) with ESMTP id E4B188E0058 for ; Mon, 4 May 2020 15:24:05 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 993254995E7 for ; Mon, 4 May 2020 19:24:05 +0000 (UTC) X-FDA: 76780012050.21.front29_23b086e6ab113 X-HE-Tag: front29_23b086e6ab113 X-Filterd-Recvd-Size: 5690 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 19:24:05 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id e25so10907008ljg.5 for ; Mon, 04 May 2020 12:24:04 -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=sPSIuUKl40zjMTrFqmrp2gFzjgO0Cf6BRDzGoK+tDWg=; b=GbV667a2pWz8YlwID7RIjSxS3EhvbGG2eVTfjeZbnaIQt36eX7hiNgbdWKkgMsOAkc Pd4c3Z36tS9zp5i+DSGGNzKx3LApW78iueZL2oOKHKQNXDEONAYw9/ZwJiiU/GAIcLEA IqcfxVY1ivCJBbIP2ttRlcjLxsjcr/HGVZqBdV7VXMRvuze/dDQrmnz2PCC0tEfr2wGb GlO3dsxskMpwBK8J2EqhuA7PAfU5gFeu1qFNUvc5mLxqLM98jDrtc9gQJG8j1w9P435i 7YmVNH9IMNHBLHEYXaU5eSxODFeYdzQ8b6i7xQ8eLdZfq67RRTA5e8VMKA/kl+4zKZjE Murw== 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=sPSIuUKl40zjMTrFqmrp2gFzjgO0Cf6BRDzGoK+tDWg=; b=SWaOmQKp19EH5cMDs9QyZ6gPWzsWA2mYA5/oVgbLOptFjn3m2iatft1lYfLkbun5IS LaApUH/hex2xBNaLdmrFqx3eQM0rgTKcIYreEsIsz1TxUGwIcpgmW3FjDyrz1y+Q9eBN vhgVNLaZsrZlhiOQRXjeNCSgrmQpc1te636u7kMDN1vTzHbqYENU+21tzHFgZ4Vp8zuv fxaKNix+FbRd5hIBFiEUaiKiKqBwkH6D1u+FGg8QBqv1tfb0trbHHMXyAqfeP4SVBJg+ +gylNKRTb99a51HKNKKUuxRtKGIcd2SQYU3q1ttcGzUV5OCJQhTKtYbiGg+k8vvEnbow IMJA== X-Gm-Message-State: AGi0PuYu52lmxloBA1fYZYPeDXLH0E1HYv0MrbilrjRsy2irZ+rxJBsA Xwz8L5yj0j6af8DaM24nC/gJwCZrYu5aQaFoI3NvOg== X-Google-Smtp-Source: APiQypK4k05/C2I/yimUeRPIsrYih0ut0hSKIXH2CCGt3+KnrSP6gGhNuIc5dVPg4hLorIO9oSIUzNKPjU1zs0K4BW4= X-Received: by 2002:a2e:9255:: with SMTP id v21mr11042631ljg.222.1588620243090; Mon, 04 May 2020 12:24:03 -0700 (PDT) MIME-Version: 1.0 References: <20200430182712.237526-1-shakeelb@google.com> <20200504065600.GA22838@dhcp22.suse.cz> <20200504141136.GR22838@dhcp22.suse.cz> <20200504150052.GT22838@dhcp22.suse.cz> <20200504160613.GU22838@dhcp22.suse.cz> In-Reply-To: <20200504160613.GU22838@dhcp22.suse.cz> From: Shakeel Butt Date: Mon, 4 May 2020 12:23:51 -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 9:06 AM Michal Hocko wrote: > > On Mon 04-05-20 08:35:57, Shakeel Butt wrote: > > On Mon, May 4, 2020 at 8:00 AM Michal Hocko wrote: > > > > > > On Mon 04-05-20 07:53:01, Shakeel Butt wrote: > [...] > > > > 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. > > > > > > It is very much a concerning reason to notify about like any other OOM > > > situation due to hard limit breach. In this case it is worse in some > > > sense because the limit cannot be trimmed down because there is no > > > directly reclaimable memory at all. Such an oom situation is > > > effectivelly conserved. > > > -- > > > > Let me make a more precise statement and tell me if you agree. The "no > > eligible task" is concerning for the charging path but not for the > > writer of memory.max. The writer can read the usage and > > cgroup.[procs|events] to figure out the situation if needed. > > I really hate to repeat myself but this is no different from a regular > oom situation. Conceptually yes there is no difference but there is no *divine restriction* to not make a difference if there is a real world use-case which would benefit from it. > Admin sets the hard limit and the kernel tries to act > upon that. > > You cannot make any assumption about what admin wanted or didn't want > to see. Actually we always make assumptions on how the feature we implement will be used and as new use-cases come the assumptions evolve. > We simply trigger the oom killer on memory.max and this is a > documented behavior. No eligible task or no task at all is a simply a > corner case For "sweep before tear down" use-case this is not a corner case. > when the kernel cannot act and mentions that along with the > oom report so that whoever consumes that information can debug or act on > that fact. > > Silencing the oom report is simply removing a potentially useful > aid to debug further a potential problem. *Potentially* useful for debugging versus actually beneficial for "sweep before tear down" use-case. Also I am not saying to make "no dumps for memory.max when no eligible tasks" a set in stone rule. We can always reevaluate when such information will actually be useful. Johannes/Andrew, what's your opinion?