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=-1.0 required=3.0 tests=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 E578AC47256 for ; Tue, 5 May 2020 07:13:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7F2EF206B8 for ; Tue, 5 May 2020 07:13:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F2EF206B8 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 A824A8E009C; Tue, 5 May 2020 03:13:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A32D28E0058; Tue, 5 May 2020 03:13:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9491A8E009C; Tue, 5 May 2020 03:13:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 8086E8E0058 for ; Tue, 5 May 2020 03:13:29 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3F5E882499B9 for ; Tue, 5 May 2020 07:13:29 +0000 (UTC) X-FDA: 76781799738.20.blade04_75b9ac60d3d31 X-HE-Tag: blade04_75b9ac60d3d31 X-Filterd-Recvd-Size: 4630 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 May 2020 07:13:28 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id l18so1358023wrn.6 for ; Tue, 05 May 2020 00:13:28 -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=D35mOJV49bWuGzt/JCgfa9WldwyA3q6GVvLou0MYSnM=; b=Y63riF+KviLXNuW/jwPTk1bvmCVKXzOrHAzsdA9cKM2MUnke0CSacUkUMC/esVNV20 qNOq0Q7iqF1zewnENKsJZzpcx51enhyCms/iJRuXSuoQq2JhObwXVJ2V1L/Fri3EnxiY IPfbJaJEzf6kxU+E29MryTCVZo5C6N/sYXQ6GBmQYIgmiVtzIRA15ncxhUyR7/SXhoVJ QYPn5pQMHroyGDDCNpEzPM3sPqckwiHnN21iBvJA++k1CLmfEcYRRGdM/5BKNBCVpqrJ wNjNZSlXvo6GhpQr3f4EB+oWfO4uqM1ycwJANrNhP95foPAl5MMI54cPnBKOTG/6bg1t ENLw== X-Gm-Message-State: AGi0Pubg9HQmD335NVJawdXKk80nYYspqDhCd5nDzIwNOMaWvqHoVVd9 66Cv00DECrU4wVekRaXy0Bg= X-Google-Smtp-Source: APiQypKsJpn506doavmId1p49nfYK71RX13vklhQ6rOpXsgAEIhvXhgtE2o2L9CsVn2B81dhZFvhfw== X-Received: by 2002:adf:f648:: with SMTP id x8mr1941180wrp.257.1588662807808; Tue, 05 May 2020 00:13:27 -0700 (PDT) Received: from localhost (ip-37-188-183-9.eurotel.cz. [37.188.183.9]) by smtp.gmail.com with ESMTPSA id u127sm2351710wme.8.2020.05.05.00.13.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 May 2020 00:13:26 -0700 (PDT) Date: Tue, 5 May 2020 09:13:24 +0200 From: Michal Hocko To: Shakeel Butt Cc: 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: <20200505071324.GB16322@dhcp22.suse.cz> 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 04-05-20 12:23:51, Shakeel Butt wrote: [...] > *Potentially* useful for debugging versus actually beneficial for > "sweep before tear down" use-case. I definitely do not want to prevent you from achieving what you want/need. Let's get back to your argument on why you cannot use memory.high for this purpose and what is the actual difference from memory.max on the "sweep before removal". You've said : Yes that would work but remote charging concerns me. Remote charging : can still happen after the memcg is offlined and at the moment, high : reclaim does not work for remote memcg and the usage can go till max : or global pressure. This is most probably a misconfiguration and we : might not receive the warnings in the log ever. Setting memory.max to : 0 will definitely give such warnings. So essentially the only reason you are not using memory.high which would effectively achieve the same level of reclaim for your usecase is that potential future remote charges could get unnoticed. I have proposed to warn when charging to an offline memcg because that looks like a sign of bug to me. Having the hard limit clamped to 0 (or some other small value) would complain loud by the oom report and no eligible tasks message but it will unlikely help to stop such a usage because, well, there is nothing reclaimable and we force the charge in that case. So you are effectively in the memory.high like situation. So instead of potentially removing a useful information can we focus on the remote charging side of the problem and deal with it in a sensible way? That would make memory.high usable for your usecase and I still believe that this is what you should be using in the first place. -- Michal Hocko SUSE Labs