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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,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 0909AC47247 for ; Tue, 5 May 2020 15:27:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A18702073B for ; Tue, 5 May 2020 15:27:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="uuzwPXhv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A18702073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 146CB8E0006; Tue, 5 May 2020 11:27:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F87F8E0003; Tue, 5 May 2020 11:27:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F286F8E0006; Tue, 5 May 2020 11:27:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id DA06D8E0003 for ; Tue, 5 May 2020 11:27:28 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 96E812826 for ; Tue, 5 May 2020 15:27:28 +0000 (UTC) X-FDA: 76783044576.11.turn14_4135899242319 X-HE-Tag: turn14_4135899242319 X-Filterd-Recvd-Size: 6053 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 15:27:27 +0000 (UTC) Received: by mail-qk1-f193.google.com with SMTP id f83so2617504qke.13 for ; Tue, 05 May 2020 08:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=r/em/r1WAWdIxfLddFgVdK8/WA54vnvCFmZ5eTaHEGI=; b=uuzwPXhvPztMz4zHd3EPswjaU7UzyVLgP82njzHGSMhiwR7satUNP/H9oFmb2zmBl5 roz08OHw6yDtf5Pytm0tv38O7lGL7Qd2QRHmJugb2TZycLQSah4WdqOk5gw599MivkHp RCDAR0ljKALkXIj6099CztWvxNRAyHv7a4ZolmsRwjb61C2Mof0IbYRyxWnMY32Qegcy BR6BEgzPa5/wJZzHwWRMvsex+cJAIMBplmh6n+c4XfhSUZwmp7EOJy4Mv3YOLsK3mTcs TXxNZEIogoS1EOphfSvEWmBrZbpPpUGSnPwBXhI/r5GnunV7OX6rnQXGolj581CtOEqP iECg== 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=r/em/r1WAWdIxfLddFgVdK8/WA54vnvCFmZ5eTaHEGI=; b=FGxad7yGQMTSH4X0OD5bNH3pN/S4ScISArBAun4K1Shg2PbkHTqbxQ0FoZsaw3trPx QS7Ym7g2FBJe9fQVhfvXtL/q3L3mSXzjuIoS5+jkEhpxBW0xDMk6mvpcGN9OPo6o3PcV huKpH0q3W8tIWQ5hfsVNTohgLgn9lXhiDoe/ogbXYpbMKnLmUZIskJdhUMIiSFmB2jHv s8vicMWxqkrMsCbdPboGEHTSnYxV3oYGgUztafI04IqxwkgISu11fGjI/NNoZsbWsIDG sY6Ddo7Fv6IjZzckHwN/0jQP+RWm3dOkEhV8GdBgS/0n9khVHDfkA3b9uvch/w5TG8Xx zBmA== X-Gm-Message-State: AGi0PuY1bYpUjOQ/jHEIVnydVwmyPyF8yFUR2ZD2ZJ5Am04GShorTB/4 qNg47ND2pygfHo+uIrCgn9hT8w== X-Google-Smtp-Source: APiQypLgzOG/9CK0nnQeafYiiDOgvjgM2U0hk8pyzzC6DGfmq/rF3w9aRNq5NZV0ftE4GOXSjn8Oaw== X-Received: by 2002:a05:620a:13f2:: with SMTP id h18mr3952397qkl.37.1588692447220; Tue, 05 May 2020 08:27:27 -0700 (PDT) Received: from localhost (70.44.39.90.res-cmts.bus.ptd.net. [70.44.39.90]) by smtp.gmail.com with ESMTPSA id a139sm2050850qkg.107.2020.05.05.08.27.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 08:27:26 -0700 (PDT) Date: Tue, 5 May 2020 11:27:12 -0400 From: Johannes Weiner To: Shakeel Butt Cc: Michal Hocko , Roman Gushchin , Greg Thelen , Andrew Morton , Linux MM , Cgroups , LKML Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max Message-ID: <20200505152712.GB58018@cmpxchg.org> 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> 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 Mon, May 04, 2020 at 12:23:51PM -0700, Shakeel Butt wrote: > On Mon, May 4, 2020 at 9:06 AM Michal Hocko wrote: > > 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. I would wholeheartedly agree with this in general. However, we're talking about the very semantics that set memory.max apart from memory.high: triggering OOM kills to enforce the limit. > > 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? I still think that if you want to sweep without triggering OOMs, memory.high has the matching semantics. As you pointed out, it doesn't work well for foreign charges, but that is more of a limitation in the implementation than in the semantics: /* * If the hierarchy is above the normal consumption range, schedule * reclaim on returning to userland. We can perform reclaim here * if __GFP_RECLAIM but let's always punt for simplicity and so that * GFP_KERNEL can consistently be used during reclaim. @memcg is * not recorded as it most likely matches current's and won't * change in the meantime. As high limit is checked again before * reclaim, the cost of mismatch is negligible. */ Wouldn't it be more useful to fix that instead? It shouldn't be much of a code change to do sync reclaim in try_charge(). Then you could express all things that you asked for without changing any user-visible semantics: sweep an empty cgroup as well as possible, do not oom on remaining charges that continue to be used by processes outside the cgroup, do trigger oom on new foreign charges appearing due to a misconfiguration. echo 0 > memory.high cat memory.current > memory.max Would this work for you?