Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3638063ybz; Mon, 4 May 2020 06:58:12 -0700 (PDT) X-Google-Smtp-Source: APiQypJ2Id7lBK4tsuKnPacgd1lgUmD2PbzY6v1xQLIkKJlOVpiUqaHw5ypMUw/fD1XJYpzkzIOu X-Received: by 2002:a05:6402:1651:: with SMTP id s17mr15171368edx.173.1588600691826; Mon, 04 May 2020 06:58:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588600691; cv=none; d=google.com; s=arc-20160816; b=j2GZitUxfv/+aX+Cfp/tBmYXejq1E8hiuDgTdJqa4Baktv1KyKyYwHY5fvsC9pDysl b44bZdMulbj+ZXXJk0UB/TniUdZuz9URg607ryEbKMXDVhfOw6N/6h//rXDjyJaRRGkJ mjtkP1Q8dG+mHYTDoqpGFCdrwIxdaNn9sHhfRe1ix3HSgVHxCwYFIqqv7KMTrqYwRzZS D7vo08mo/PKwKkY1Cl/OwV/TN45ONwVTOI3HKqYwu1SLk8Qa4y5wkcSY8J+4dyZeg5eU s4YnlNnD7O0k1gcO4HkcEUSb3uttITTFSx74QY6S92Jsg9WKS5XJDzWInhChNviVsoeJ p9uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Itdyqr8e224xa0qoeMb+hZq4gtZJw27Kt/U4OO6UwfY=; b=pRss5qT6wlkZoF+fjE1xhAM+o3CD4AMMUFqOHuybKdE2tl5RDHVIXqWJsRXRKhP8T8 ZVpIsZUBSz3wKU60QeZkNE9D0zUlG0FKigG/w3/aQbqeO58lcYri7r/n/kp+sMpM9+D5 /4mDmn1zGx4/oRcUlVkOapY08WPWc4u5AV7IPZyQFPSeNEHqUK0uNbyssY3BZKbjlRRK apR3Xdw0l9LKmVV51KiMQLapOBZgxsxZ/8k2GhzVRs2krIShGhvZ8oqhNr+p8c/MRynl t+WRTKWdvr0X6/EQ8TN/2wfBHtarxBKEP/O7SmkyJEDxFypI21Dw00zINV3FQhmHWx/3 giMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="VwcmkO0/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si6748697edr.382.2020.05.04.06.57.48; Mon, 04 May 2020 06:58:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="VwcmkO0/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728334AbgEDNzC (ORCPT + 99 others); Mon, 4 May 2020 09:55:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726404AbgEDNzB (ORCPT ); Mon, 4 May 2020 09:55:01 -0400 Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E592C061A0F for ; Mon, 4 May 2020 06:55:01 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id h4so9718815ljg.12 for ; Mon, 04 May 2020 06:55:01 -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=Itdyqr8e224xa0qoeMb+hZq4gtZJw27Kt/U4OO6UwfY=; b=VwcmkO0/GGrS6n5JI5GYBP8kGrKFLTo2xvM2ArBj0wbbTAFiLbviLMWKFElUpB1u6f WgULsIHvmc25XtTe+aJFycilL4dmDvYQXBjgWFAqwh6WcFlGwUP/KZN3Izhl5TPyVYWx G28TYGCkekQgzmA9OTUzT3vDw78RBR1mtkmpHdpljY6SYmnD2iBGW25ClTOYDjONv/DZ 4dAknYrGHYB8MFaPSTGCOfozIdR+Z2EP6rW2LI59ejQ8A8zk69BN9FX540dADpBvZWg4 AHm0elYmxfpvuY5b9nbJ9Bpb+6pyYKLZmUTWEUuMAMpCQzn3eLMnlpgruHUEUJdyhwJ7 kVjw== 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=Itdyqr8e224xa0qoeMb+hZq4gtZJw27Kt/U4OO6UwfY=; b=Rk4oBwfdtBbx9hAaxe/dxlyw1fQRxNvcc9ql9rOyvLbYv+dOAKrCDR8he/1z4rOPiw JpZg8xj6T8sXM9NLP2z/kJ+7ulmDGhzD2MbFHw4rnt4Hz128+Lk74ElZ/G6G7bJGjbG8 /RoiTnM1W8A19u2GI55yJpptYMgvSEaN7uOsJBLdnPB7jlxhzhrSL1mT2LbBGPVsNif/ YXMo7Uif0YBBXwnfuyg+cNt96sZ0kIHf0CblEpSBmG0Pi8GgAVHmOoIql6d86hXpeos+ DhQlsZD2rsGHUtHxZJOedLvaVw7BQEsg+ruF9+9pYo4NNCvSnfBOERjHtNATRNZg/Aj4 5FcA== X-Gm-Message-State: AGi0PubM+K5S1aB4hu1LUIeaPwgtUtK02bFcuLp4wGp/g4xoVD1j7Yol XnsZkevZhdxVGXJyxEZ3qCa7brPlXzCKCtxNOsGugQ== X-Received: by 2002:a2e:330f:: with SMTP id d15mr9701206ljc.250.1588600499500; Mon, 04 May 2020 06:54:59 -0700 (PDT) MIME-Version: 1.0 References: <20200430182712.237526-1-shakeelb@google.com> <20200430192907.GA2436@cmpxchg.org> <20200504065701.GB22838@dhcp22.suse.cz> In-Reply-To: <20200504065701.GB22838@dhcp22.suse.cz> From: Shakeel Butt Date: Mon, 4 May 2020 06:54:47 -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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 3, 2020 at 11:57 PM Michal Hocko wrote: > > On Thu 30-04-20 13:20:10, Shakeel Butt wrote: > > On Thu, Apr 30, 2020 at 12:29 PM Johannes Weiner wrote: > > > > > > On Thu, Apr 30, 2020 at 11:27:12AM -0700, 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. > > > > > > > > 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. > > > > > > Can't you set memory.high=0 instead? It does the reclaim portion of > > > memory.max, without the actual OOM killing that causes you problems. > > > > 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. > > Can we add a warning for the remote charging on dead memcgs? > I don't think we should warn for all remote charging on dead memcgs. One particular example is the buffer_head which can be allocated within reclaim context and most probably pages which they are attached to will be freed soon. Shakeel