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.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 24C62C3A5A9 for ; Mon, 4 May 2020 15:25:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C38C020735 for ; Mon, 4 May 2020 15:25:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="UmgtRZ+e" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C38C020735 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 582FC8E004C; Mon, 4 May 2020 11:25:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50BF48E0024; Mon, 4 May 2020 11:25:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FD118E004C; Mon, 4 May 2020 11:25:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id 24C878E0024 for ; Mon, 4 May 2020 11:25:13 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DF5D18249980 for ; Mon, 4 May 2020 15:25:12 +0000 (UTC) X-FDA: 76779410064.06.tax40_84ceed9ad735f X-HE-Tag: tax40_84ceed9ad735f X-Filterd-Recvd-Size: 6906 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 May 2020 15:25:12 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id d7so7818315ioq.5 for ; Mon, 04 May 2020 08:25:12 -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=AlUH+IxfQhZ703OmQAh2ycVXQLxCz4bnHl+PKNMYj5U=; b=UmgtRZ+eJ6ESDteZu6dQC9WHyqy0d9d4n7f31Vp59Oa41qyX14ZiL0SpND8f0mFOOv LkamC0+SibBEW6YKBzic480HbiZgR1OdXcg2DNWgDxOUsJR+K8Y2pegozl1VCF9r5gpp wo+rb8W0SZqWZQEchNBuP57TNR9DnVKgmMD7/JEYi2rRwBPPoWPH6iCLvsdAi8YDDEJ7 kis8h6HoyNP1aM5LfqedO/hhJ8p9lj0qJZBlfcCxStUBhsJpGsKiUcRG00VoNNbsZ/ya qov86Fy3D6eBB1m81muxhBhpVDfKyQ2mLFotLvYR2Nr3FRNkvoUwvn9TxVptQ1rbWSRb 7XVw== 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=AlUH+IxfQhZ703OmQAh2ycVXQLxCz4bnHl+PKNMYj5U=; b=I34MUFG8iH19oXr8cvrUe/XEUxajFuFi2hgIDhhmAVkFTLZrXl1mfu3WnKnhH0jdLD G/r5+zIrwnhh1tcpYeeoqyqfOZq/7jgGXVAypCxJGSvpI4J73g0O/2ANPXwp6263APxH 86yoPT25q16AxA7AH+DX4IY10ImTBVeJOaHkAHrUvfEj6aSfQ8ulhtv6UGX4b2bTRu4w 18Fw61skfc3L2VYwJWPLGerbrf3N09j0ALdbT9v305ym8hjmTL3BYRyCpbhIR/TirHgZ G2RDiPEaXeN5sw8hkpynjF83AcKAOuUnD+Mz4q150N743SunxRpm4vcISui/oYCDjvuk wCAQ== X-Gm-Message-State: AGi0PuZitjbzeeO69Z3JGZUZ2Re/oLa4u41hucpTqwpYjSV80Gfkoys1 8MZSe9btJavY0dW+akmD/DbNqyzN24TKGKa4R6M= X-Google-Smtp-Source: APiQypL0nVquf1MaJOHU6IZDh7+lHLTdcSD91e4GIIeZgNR04dQoVAAgZ0TpaBOSbnuuPkTaTcmP8hCMc26iyl1C2Ew= X-Received: by 2002:a6b:e719:: with SMTP id b25mr15846457ioh.81.1588605911930; Mon, 04 May 2020 08:25:11 -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> <20200504124627.GP22838@dhcp22.suse.cz> In-Reply-To: <20200504124627.GP22838@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 4 May 2020 23:24:35 +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 8:46 PM Michal Hocko wrote: > > On Mon 04-05-20 20:34:01, Yafang Shao wrote: > > 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. > > You are right. The oom situation will be reported (somehow) but the > reason why no task has been killed might be several and there is no way > to report no eligible tasks. > > > 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. > > But the oom situation and the oom report is simply something an admin > has to expect especially when the hard limit is set to 0. With kmem > accounting there is no guarantee that the target will be met. I'm always wondering that why not moving the kmem from this memcg to the root_mem_cgroup in this situation ? Then this memcg can be easily reclaimed. > > > > > > > Besides that I really do not see any actual problem that this would be > > > fixing. > > > > Avoid printing two many oom logs. > > There is only a single oom report printed so I disagree this is really a > proper justification. > > Unless you can come up with a better justification I am against this > patch. It unnecessarily reduce debugging tools while it doesn't really > provide any huge advantage. Changing the hard limit to impossible target > is known to trigger the oom kernel and the oom report is a part of that. > If the oom report is too noisy then we can discuss on how to make it > more compact but making ad-hoc exceptions like this one is not a good > solution. > -- No better justification yet. But I think more memcg users will complaining about it. -- Thanks Yafang