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 4BD12C47254 for ; Tue, 5 May 2020 15:36:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 08B7D206B9 for ; Tue, 5 May 2020 15:35:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="o/lrwQCJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08B7D206B9 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 956DC8E0005; Tue, 5 May 2020 11:35:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 908098E0003; Tue, 5 May 2020 11:35:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81CA88E0005; Tue, 5 May 2020 11:35:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 67DBC8E0003 for ; Tue, 5 May 2020 11:35:59 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0E88616E11 for ; Tue, 5 May 2020 15:35:59 +0000 (UTC) X-FDA: 76783066038.24.bead26_8b802f649ee46 X-HE-Tag: bead26_8b802f649ee46 X-Filterd-Recvd-Size: 6131 Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 15:35:58 +0000 (UTC) Received: by mail-lf1-f67.google.com with SMTP id h26so1726765lfg.6 for ; Tue, 05 May 2020 08:35:58 -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=huzUgNgktrhOCuskegeISs0vb5n+2XRI/TAh0nK4ACg=; b=o/lrwQCJd50bIYfIsq0VJczMjBR58BsANK+atKw0wvz6n+yx9YZx/Nc940iF+0GKBy hLX1vW57uKXqlQoqbEXWwWB2OPzsPSs/1Xv/IRnVkZZWUic1oqJOZTjNYVBgM85e4p9T q8V0YzTKSnkWNS653jK6QCarT5rXXuYcYhLL6Xto3yX0F2uUtYNLwFfjKikUad8LtsLY ciEJ2WNrIfEJBpPgnOwymUO911icskpbfrUvh1BEasE+MWoaV1+0SJoxVx7syjB0Tn6T ClJ0LaUAT1XBPSTG5mhidZZSbLV0oOhaHpAYDKo6GLj1Yk57GrgqZdRwIiAP3TPvUzfi scRw== 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=huzUgNgktrhOCuskegeISs0vb5n+2XRI/TAh0nK4ACg=; b=m3LpIoWum4HkJ06Y41S3SwWr9lmioRkM3SY74C0qYBCcBiy6U7Gwj9aDEAynZ2uL+d OJ3/WvqWmR2r5y1ZlyNyb4SktuNpw+ABAPDynhmIE/DANyrY7zbOR+ZGoW/nCZmTib36 Z7IK761/YMXNI7MHjiWG/dyoJmrgDxQGJwsAV9pfkIVnf1OwAVDyc+TJvnIAXsC8mILB 7lAF2zYmsg9nR2F6USXs6osm/nTS5dSbY5kKlymA5vSaj7MRx+D84ai/34HR02mlMbYE 1TFYfxUlBkJFlr1YD4Fb0sZqi/ufBlMhqHXT6dTCS5I6g4WoNcKOx9AvQLGRYQ4qX+AE wj1Q== X-Gm-Message-State: AGi0PuZ3+/P2x6USoSWsnAJbPgy+QhnDJ/24NI77np6Asry3C6BfK+Su Vu7RJvNDArkXhSQhym5m0nSr3CU5oUOrFlz/Mlw3BQ== X-Google-Smtp-Source: APiQypLnRYOoUJwZCqblQY9KaIwvVTlVdl1d9jFGkPlVkiHRoPkT9L7oyjRWTeGVG6V/2ICMPJ5TIkqiS2OgBQIs4Jg= X-Received: by 2002:ac2:4466:: with SMTP id y6mr2067094lfl.125.1588692956784; Tue, 05 May 2020 08:35:56 -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> <20200505152712.GB58018@cmpxchg.org> In-Reply-To: <20200505152712.GB58018@cmpxchg.org> From: Shakeel Butt Date: Tue, 5 May 2020 08:35:45 -0700 Message-ID: Subject: Re: [PATCH] memcg: oom: ignore oom warnings from memory.max To: Johannes Weiner Cc: Michal Hocko , 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 Tue, May 5, 2020 at 8:27 AM Johannes Weiner wrote: > > 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(). Sync reclaim would really simplify the remote charging case. Though should sync reclaim only be done for remote charging or for all? > > 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? Yes that would work. I will work on a patch.