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=-5.5 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 C5DDCC432C0 for ; Wed, 20 Nov 2019 10:22:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 763E22243E for ; Wed, 20 Nov 2019 10:22:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 763E22243E 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 D0D1B6B000A; Wed, 20 Nov 2019 05:22:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CBCE46B000C; Wed, 20 Nov 2019 05:22:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B357F6B000D; Wed, 20 Nov 2019 05:22:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id 9B9426B000A for ; Wed, 20 Nov 2019 05:22:01 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 21B9E2C94 for ; Wed, 20 Nov 2019 10:22:01 +0000 (UTC) X-FDA: 76176265242.01.blood99_2ead4cabce44b X-HE-Tag: blood99_2ead4cabce44b X-Filterd-Recvd-Size: 5037 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Wed, 20 Nov 2019 10:22:00 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id q70so6363560wme.1 for ; Wed, 20 Nov 2019 02:22:00 -0800 (PST) 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:user-agent; bh=NhynAAl66KdoRtVpdtFZCn3nkoFn7OKgqegahUkD++g=; b=mA9QjvSYeQoOqULEFxiXVULU7FrjKO6COtm+DvXTxepFJSNnr7uP4wALKW+Ds9PhsU I8vzRV6BUqy18yi1qLD/eIOq5iEEFxEFkC9xY+mVqf9JPhfOc6+7Op9e6BMzHTb8f/7Q hTY2barXR7WpbSXYG0KSjcBe/k6KCTOYwTcx3kwn71HuxI6ms1UbF6FD6ABVTaoE1D6X LvROgDagIlsHjyuEsA//MCzSSxSyqpBjpgr1iwsjSEgfBmOuJmBszAEyKfJWYcd0TmW5 CD6krcAcfLa0SGSbEOuLyHBjxE3jUpqJiSbAuEVhiI7y5psql02f6h3g0P0NZz1hgWaN JknQ== X-Gm-Message-State: APjAAAUFl2dCW7DQRp/T3Yt56lgBr+huSrRg8T88BJ5fK7hyeCWp7Tn4 1PPvPTqfZHYy4QIUihJlzro= X-Google-Smtp-Source: APXvYqybLfswswSw1JZCL+y5LXQUG3rgAqcoRlhiKuIL4/bd64A5xma70FTdVCI6pPVhtmCLjxEloQ== X-Received: by 2002:a1c:7e0e:: with SMTP id z14mr2379678wmc.52.1574245319422; Wed, 20 Nov 2019 02:21:59 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id s17sm5904631wmh.41.2019.11.20.02.21.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Nov 2019 02:21:58 -0800 (PST) Date: Wed, 20 Nov 2019 11:21:57 +0100 From: Michal Hocko To: Yafang Shao Cc: hannes@cmpxchg.org, vdavydov.dev@gmail.com, akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [PATCH] mm, memcg: show memcg min setting in oom messages Message-ID: <20191120102157.GF23213@dhcp22.suse.cz> References: <1574239985-1916-1-git-send-email-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1574239985-1916-1-git-send-email-laoar.shao@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Wed 20-11-19 03:53:05, Yafang Shao wrote: > A task running in a memcg may OOM because of the memory.min settings of his > slibing and parent. If this happens, the current oom messages can't show > why file page cache can't be reclaimed. min limit is not the only way to protect memory from being reclaim. The memory might be pinned or unreclaimable for other reasons (e.g. swap quota exceeded for memcg). Besides that, there is the very same problem with the global OOM killer, right? And I do not expect we want to print all memcgs in the system (this might be hundreds). > So it is better to show the memcg > min settings. > Let's take an example. > bar bar/memory.max = 1200M memory.min=800M > / \ > barA barB barA/memory.min = 800M memory.current=1G (file page cache) > barB/memory.min = 0 (process in this memcg is allocating page) > > The process will do memcg reclaim if the bar/memory.max is reached. Once > the barA/memory.min is reached it will stop reclaiming file page caches in > barA, and if there is no reclaimable pages in bar and bar/barB it will > enter memcg OOM then. > After this pacch, bellow messages will be show then (only includeing the > relevant messages here). The lines begin with '#' are newly added info (the > '#' symbol is not in the original messages). > memory: usage 1228800kB, limit 1228800kB, failcnt 18337 > ... > # Memory cgroup min setting: > # /bar: min 819200KB emin 0KB > # /bar/barA: min 819200KB emin 819200KB > # /bar/barB: min 0KB emin 0KB > ... > Memory cgroup stats for /bar: > anon 418328576 > file 835756032 > ... > unevictable 0 > ... > oom-kill:constraint=CONSTRAINT_MEMCG..oom_memcg=/bar,task_memcg=/bar/barB > > With the new added information, we can find the memory.min in bar/barA is > reached and the processes in bar/barB can't reclaim file page cache from > bar/barA any more. While without this new added information we don't know > why the file page cache in bar can't be reclaimed. Well, I am not sure this is really usefull enough TBH. It doesn't give you the whole picture and it potentially generates a lot of output in the oom report. FYI we used to have a more precise break down of counters in memcg hierarchy, see 58cf188ed649 ("memcg, oom: provide more precise dump info while memcg oom happening") which later got rewritten by c8713d0b2312 ("mm: memcontrol: dump memory.stat during cgroup OOM") Could you be more specific why do you really need this piece of information? > Signed-off-by: Yafang Shao > --- > mm/memcontrol.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) -- Michal Hocko SUSE Labs