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=-6.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 58E96C3A5A9 for ; Mon, 4 May 2020 12:34:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0BF1D206B9 for ; Mon, 4 May 2020 12:34:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="g++wqsRu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BF1D206B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8244D8E0005; Mon, 4 May 2020 08:34:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D4158E0003; Mon, 4 May 2020 08:34:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EA128E0005; Mon, 4 May 2020 08:34:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 54C988E0003 for ; Mon, 4 May 2020 08:34:38 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1A815181AC9C6 for ; Mon, 4 May 2020 12:34:38 +0000 (UTC) X-FDA: 76778980236.25.light23_62a4f33a9f11f X-HE-Tag: light23_62a4f33a9f11f X-Filterd-Recvd-Size: 6927 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 12:34:37 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id 19so12015844ioz.10 for ; Mon, 04 May 2020 05:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z7t1lU7FUHzNLWzFWbalwHDNIvUFMHXDfj/qGNA/8vo=; b=g++wqsRuAGmQGdTm6dGGB3duGHpdB1g2uWbZne+BgfvfeIRLldiB7/SOId4VDuxus6 +su7GyzB+nTU5iW44AAOnMnpvrtZ+begcJj0Uxme5RmvAM6MnL3YYd/TI/WlmTSvJX/l R8zgMsHOgr/YqD90jA94sx+F2tPjdP6p/ySJdeVAtWnMHcR3DUzQib6hVaEKBOSq0utY hTZQB+UBXIWhdQ9LvjMfvoA4GH1ez7c/HCuEjeJ/HG+UCQ6p/XjZFd0am70prSaqq0A4 6i+mawcTDCNUtxjyPZqhsUCakaFIzVdv4AK/dLuefp30kLbBXqkxf6PGN7I27UFjznc6 WW9w== 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=z7t1lU7FUHzNLWzFWbalwHDNIvUFMHXDfj/qGNA/8vo=; b=XCXXAicKIX6xoIuU8vNTcIJdlsABrikB+/SW//1tKzGf1cjN9Kgs6zgHr041imuNVQ CTUuh/c0zgAJYwws2CgE9VMMBiIpF5f6Af+E2ULa1+toIqpUBaZaLGOgEacY5f2R05Lo gneaxQOyFo2Fw7/bAkYznB872pdO1/67U9szNXyersmnMgSDJsgP/nKAq5JbL3qDG1Nj qkQPw9rPHOBP06qlvt1Ln0THGrZoGB3oGlzSwth6cWSjrrcWaRVJEFxlKKwAKrhsC8UD 7qVv4lDjmpsrmg/I6v4JjSs2dAPl36189ZzAAiEMJ027MG/kWel9EklgARuS720IKNgo iuPQ== X-Gm-Message-State: AGi0Puat2mcIonzQ+4xyMbAdrHu8Zrk7kS2W7bEzeQbuB92qetOQjhTK pznW8oaJL6G9rzaCgq3lwCHGkvmUJamgk2UEzzc= X-Google-Smtp-Source: APiQypK3YUOFAFT02FIOivXKAdkPCuIGRfJ8e7XgHMPbI02ZxyZ8uJOpYLD7zHiBAPiCpTE4+UWylpfQ+0mN0n+7AFo= X-Received: by 2002:a05:6602:1d0:: with SMTP id w16mr15157547iot.13.1588595677114; Mon, 04 May 2020 05:34:37 -0700 (PDT) MIME-Version: 1.0 References: <20200504042621.10334-1-laoar.shao@gmail.com> <20200504042621.10334-3-laoar.shao@gmail.com> <20200504081848.GJ22838@dhcp22.suse.cz> In-Reply-To: <20200504081848.GJ22838@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 4 May 2020 20:34:01 +0800 Message-ID: Subject: Re: [PATCH v2 2/2] mm, memcg: don't try to kill a process if memcg is not populated To: Michal Hocko Cc: Andrew Morton , Shakeel Butt , Johannes Weiner , Roman Gushchin , Greg Thelen , Linux MM 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 4:18 PM Michal Hocko wrote: > > [It would be really great if a newer version was posted only after there > was a wider consensus on the approach.] > > On Mon 04-05-20 00:26:21, Yafang Shao wrote: > > Recently Shakeel reported a issue which also confused me several months > > earlier. Bellow is his report - > > 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 of un-needed warnings. So, ignore all such warnings from memory.max. > > > > A better way to avoid this issue is to avoid trying to kill a process if > > memcg is not populated. > > Note that OOM is different from OOM kill. OOM is a status that the > > system or memcg is out of memory, while OOM kill is a result that a > > process inside this memcg is killed when this memcg is in OOM status. > > Agreed. > > > That is the same reason why there're both MEMCG_OOM event and > > MEMCG_OOM_KILL event. If we have already known that there's nothing to > > kill, i.e. the memcg is not populated, then we don't need a try. > > OK, but you are not explaining why a silent failure is really better > than no oom report under oom situation. With your patch, there is > no failure reported to the user and there is also no sign that there > might be a problem that memcg leaves memory behind that is not bound to > any (killable) process. This could be an important information. > That is not a silent failure. An oom event will be reported. The user can get this event by memory.events or memory.events.local if he really care about it. Especially when the admin set memory.max to 0 to drop all the caches, many oom logs are a noise, besides that there are some side effect, for example two many oom logs printed to a slow console may cause some latency spike. > Besides that I really do not see any actual problem that this would be > fixing. Avoid printing two many oom logs. > Reducing the hard limit is an operation which might trigger the > oom killer and leave an oom report behind. Having an OOM without any > tasks is pretty much a corner case and making it silent just makes > it harder to debug. > This can only happen when the admin reduces memory.max, and the admin should have the ability to know how to get the result, for example by memory.events. > > Basically why setting memory.max to 0 is better than setting memory.high to > > 0 before deletion. The reason is remote charging. High reclaim does not > > work for remote memcg and the usage can go till max or global pressure. > > > > [shakeelb@google.com: improve commit log] > > Signed-off-by: Yafang Shao > > Reviewed-by: Shakeel Butt > > Cc: Johannes Weiner > > Cc: Michal Hocko > > Cc: Roman Gushchin > > Cc: Greg Thelen > > --- > > mm/memcontrol.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 985edce98491..29afe3df9d98 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -6102,6 +6102,10 @@ static ssize_t memory_max_write(struct kernfs_open_file *of, > > } > > > > memcg_memory_event(memcg, MEMCG_OOM); > > + > > + if (!cgroup_is_populated(memcg->css.cgroup)) > > + break; > > + > > if (!mem_cgroup_oom_kill(memcg, GFP_KERNEL, 0)) > > break; > > } > > -- > > 2.18.2 > > -- > Michal Hocko > SUSE Labs -- Thanks Yafang