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 EAADAC432C0 for ; Tue, 26 Nov 2019 14:52:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E61F2071A for ; Tue, 26 Nov 2019 14:52:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="t+/bdHy4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E61F2071A 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 0D27D6B031C; Tue, 26 Nov 2019 09:52:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0837C6B031D; Tue, 26 Nov 2019 09:52:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDB876B031E; Tue, 26 Nov 2019 09:52:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id D8D496B031C for ; Tue, 26 Nov 2019 09:52:07 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 850BD8249980 for ; Tue, 26 Nov 2019 14:52:07 +0000 (UTC) X-FDA: 76198718694.26.door99_86e99947f5b12 X-HE-Tag: door99_86e99947f5b12 X-Filterd-Recvd-Size: 6465 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 Nov 2019 14:52:06 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id r9so17834300ilq.10 for ; Tue, 26 Nov 2019 06:52:06 -0800 (PST) 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=4xzuNClLTq6A8ljuZ7jUfDH5bv6rdA+U06euGYOyjWk=; b=t+/bdHy4AfbWo6BeA6/VrMcw0pRzEYsxsD6lCU7qajp8uf1QiD242eLNG7JZkeg3BY WKOLoBPOrbEMPwTqHgXPeX35A0r+kLrWlquWENqe6wS0Rad3yiWU9QpWuaJrq3uRTnPy s1x3ei3GAbeIsxVZc3AFK91iTl6w1CDdgnV+Xn1ThYC6ViQ+rriJkpnKkMqoLrV1irRI cT6e7dHNlRxODID8ljLtKpdghEVTDBdFs6wB9Zz1702zIwxZ9opg2lVWdPklg7BT0nWf bYNtYZQbR+gvp55REfJrUsvCUiFDovRp0NEfqh0aXz0vI9KPgnElVgtGg5kiTSlriUBB Vfvw== 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=4xzuNClLTq6A8ljuZ7jUfDH5bv6rdA+U06euGYOyjWk=; b=HvRrYDI71ziwsLNZkgrqnWQhoODrhjPs7l0ADcbenUQ1gY8cNk2KnknAQmky6cO1mW nl9yHHyCCU4wDtyQg/KSSvR4Jhg/1yiweOoRL0xCgtujKWsYSn1vhZdTXRaQTIYgxkhc SA0fIBINaLK7fAvmkP7hRtA9guPXKgQUFD6HTKHISnFh1YtpZjBLlsEUFtFk50BJoYWW 1ceWCbTKNQI27As0wUQcMrb4ULumwDLFJ0VGkT96wPKqbJRbMou420XB0PmkzplCugrj A/Uf9hY//P7qovj99ZgVztYFwma4fY3QcpGew2c7+dkxSO+m0l2JJMFQeFKHNTvqUGo8 Memw== X-Gm-Message-State: APjAAAVawUA2vlp6P8MrfluLQ6mg2VS/tU615ezFRUmfyG2Q5kbcvMxB sJ8Yn+Yq+DytXQJTrfEINza8J8qYWaffiKD66Ww= X-Google-Smtp-Source: APXvYqyWfD8qQUsRreYkKku9kIKex0XokOJlRkw6Mpeix89Np4DVADHyeZnYCDA+XrDKatYjypMA4sIWQ4J+19iiPT8= X-Received: by 2002:a92:358d:: with SMTP id c13mr3239942ilf.168.1574779925833; Tue, 26 Nov 2019 06:52:05 -0800 (PST) MIME-Version: 1.0 References: <1574773369-1634-1-git-send-email-laoar.shao@gmail.com> <20191126131604.GF20912@dhcp22.suse.cz> <20191126144510.GH20912@dhcp22.suse.cz> In-Reply-To: <20191126144510.GH20912@dhcp22.suse.cz> From: Yafang Shao Date: Tue, 26 Nov 2019 22:51:30 +0800 Message-ID: Subject: Re: [PATCH] mm, memcg: avoid oom if cgroup is not populated To: Michal Hocko Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , 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 Tue, Nov 26, 2019 at 10:45 PM Michal Hocko wrote: > > On Tue 26-11-19 22:25:27, Yafang Shao wrote: > > On Tue, Nov 26, 2019 at 9:16 PM Michal Hocko wrote: > > > > > > On Tue 26-11-19 08:02:49, Yafang Shao wrote: > > > > There's one case that the processes in a memcg are all exit (due to OOM > > > > group or some other reasons), but the file page caches are still exist. > > > > These file page caches may be protected by memory.min so can't be > > > > reclaimed. If we can't success to restart the processes in this memcg or > > > > don't want to make this memcg offline, then we want to drop the file page > > > > caches. > > > > The advantage of droping this file caches is it can avoid the reclaimer > > > > (either kswapd or direct) scanning and reclaiming pages from all memcgs > > > > exist in this system, because currently the reclaimer will fairly reclaim > > > > pages from all memcgs if the system is under memory pressure. > > > > The possible method to drop these file page caches is setting the > > > > hard limit of this memcg to 0. Unfortunately this may invoke the OOM killer > > > > and generates lots of misleading outputs, that should not happen. > > > > > > I disagree that the output is misleading. Quite contrary, it provides a > > > useful lead on the unreclaimable memory. > > > > > > > We can show the unreclaimable memory independently, rather than print > > the full oom output. > > OOM killer is used to kill process, why do we invoke it when there's > > no process ? > > What's the advantage of doing it ? > > Consistency. > If there are tasks, we invoke the OOM killer to try to kill the tasks. If there're no tasks, we just try to free the reclaimable pages. Why do you think this is NOT Consistency? Regarding the output, why should we distinguish the system OOM and memcg OOM, and why do you think this is Consistency ? > > > > One misleading output is "Out of memory and no killable processes...", > > > > while really there is no tasks rather than no killable tasks. > > > > > > Again, this is nothing misleading. No task is a trivial subset of no > > > killable task. I do not see why we should treat one differently than the > > > other. > > > > > > > No killable tasks means there's task and the OOM killer may be invoked. > > While no tasks means the OOM killer is useless. > > I disagree. > > > > > Furthermore, > > > > the OOM output is not expected by the admin if he or she only wants to drop > > > > the cahes and knows there're no processes running in this memcg. > > > > > > But this is not what hard limit reduced to 0 really does. No matter > > > whether there is some task or not. It simply reclaims _all_ the memory > > > as explained in other email. > > > > > > > Are there any way to reclaim page cache only ? > > No. > > Correct. And in absence of a solid usecase then I do not see a reason to > add this. We have a global knob to achieve this and it has turned out to > be abused and just used incorrectly most of the time. > > > I know it will relcaim all the memory. > > If you really think this expression is a prolem, but does it > > improtant that we should distingush between caches (both page caches > > and kmem) and _all_ memory, especially when there's no processes ? > > I do not think we should distinguish different memory types and treat > them differently when applying hard limit. > -- It doesn't matter with different memory types. It really matters with if there is no such memory that we don't need to waster our time to handle it. Thanks Yafang