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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 0BBBFC432C0 for ; Mon, 25 Nov 2019 09:27:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C736D20823 for ; Mon, 25 Nov 2019 09:27:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C736D20823 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 788DC6B05CA; Mon, 25 Nov 2019 04:27:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75F516B05CB; Mon, 25 Nov 2019 04:27:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69C7D6B05CC; Mon, 25 Nov 2019 04:27:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id 54E216B05CA for ; Mon, 25 Nov 2019 04:27:08 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id E819D181AEF21 for ; Mon, 25 Nov 2019 09:27:07 +0000 (UTC) X-FDA: 76194270894.08.ship25_3f9e79c58726 X-HE-Tag: ship25_3f9e79c58726 X-Filterd-Recvd-Size: 6749 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 Nov 2019 09:27:07 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id z3so16990723wru.3 for ; Mon, 25 Nov 2019 01:27:07 -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=wwVl4jWZFF59wlSs2VE/sL9b2K2TSLcqZYInj9y1jIY=; b=ZsERrofnMGQRt5FtoDzzWfE27cWpvBnASi+7x39FaHcHTGUa4fmAYkaftT4b6bDjEi 1KKDhG37Dxn1Mo3uotnRERq/CowJsrdNfQytEI8SiiTxVwtIAJcsZ2ZwhpOqcI+XvC3d /gRuWPbKjfCgg/YwCAmEya7ZFjnOMeUaHfn+nz+Xs0n6ARAU/a1t5uJXGopSVXuojf8q pld3gNwVEx4c1bPCQxhIokZKFbFObE5Tzdeo3QMasHziblPmGhaohk3dfiphaUUrv6Ty kI8SCtTwreAxTojqWfVkfeBga1EHwxuhXAhVp7DTdkyANGPouzFL6nHhuAZ3Ty9V5OSh ZtAQ== X-Gm-Message-State: APjAAAUcZrDnkxAKR+syopPKsoVUUq3etUyJexPK3qr5+1M/2b944anl OLb0YeH6E2fPt0CwU7Hdk20= X-Google-Smtp-Source: APXvYqwn9daGEbqpTPXnWj+ZilbQ5mcipr4Rgj2/ScwXKkpZax2yxhJUksVNnd5JVptbHQ5OXNkfTg== X-Received: by 2002:a5d:55c5:: with SMTP id i5mr32427713wrw.385.1574674026304; Mon, 25 Nov 2019 01:27:06 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id w4sm8058219wmk.29.2019.11.25.01.27.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Nov 2019 01:27:05 -0800 (PST) Date: Mon, 25 Nov 2019 10:27:04 +0100 From: Michal Hocko To: Yafang Shao Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Linux MM Subject: Re: [PATCH] mm, memcg: show memcg min setting in oom messages Message-ID: <20191125092704.GE31714@dhcp22.suse.cz> References: <1574239985-1916-1-git-send-email-laoar.shao@gmail.com> <20191120102157.GF23213@dhcp22.suse.cz> <20191120114043.GH23213@dhcp22.suse.cz> <20191122102842.GR23213@dhcp22.suse.cz> <20191125082040.GB31714@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 25-11-19 17:12:54, Yafang Shao wrote: > On Mon, Nov 25, 2019 at 4:20 PM Michal Hocko wrote: > > > > On Sat 23-11-19 13:52:57, Yafang Shao wrote: > > > On Fri, Nov 22, 2019 at 6:28 PM Michal Hocko wrote: > > > > > > > > On Wed 20-11-19 20:23:54, Yafang Shao wrote: > > > > > On Wed, Nov 20, 2019 at 7:40 PM Michal Hocko wrote: > > > > > > > > > > > > On Wed 20-11-19 18:53:44, Yafang Shao wrote: > > > > > > > On Wed, Nov 20, 2019 at 6:22 PM Michal Hocko wrote: > > > > > > > > > > > > > > > > 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). > > > > > > > > > > > > > > Both swap or unreclaimabed (unevicteable) is printed in OOM messages. > > > > > > > > > > > > Not really. Consider a memcg which has reached it's swap limit. The > > > > > > anonymous memory is not really reclaimable even when there is a lot of > > > > > > swap space available. > > > > > > > > > > > > > > > > The memcg swap limit is already printed in oom messages, see bellow, > > > > > > > > > > [ 141.721625] memory: usage 1228800kB, limit 1228800kB, failcnt 18337 > > > > > [ 141.721958] swap: usage 0kB, limit 9007199254740988kB, failcnt 0 > > > > > > > > But you do not have any insight on the swap limit down the oom > > > > hierarchy, do you? > > > > > > > > > > > Why not just print the memcgs which are under memory.min protection or > > > > > > > something like a total number of min protected memory ? > > > > > > > > > > > > Yes, this would likely help. But the main question really reamains, is > > > > > > this really worth it? > > > > > > > > > > > > > > > > If it doesn't cost too much, I think it is worth to do it. > > > > > As the oom path is not the critical path, so adding some print info > > > > > should not add much overhead. > > > > > > > > Generating a lot of output for the oom reports has been a real problem > > > > in many deployments. > > > > > > So why not only print non-zero counters ? > > > If some counters are 0, we don't print them, that can reduce the oom reports. > > > > > > Something like "isolated_file:0 unevictable:0 dirty:0 writeback:0 > > > unstable:0" can all be removed, > > > and we consider them as zero by default. > > > > because that would make parsing more complex. > > > > > I mean we can optimze the OOM reports and only print the useful > > > information to make it not be a problem in many deployments. > > > > We can, but it would be great to have it backed by som real usecase to > > change the current behavior. I haven't heard anything so far. It is all > > about "this would be nice" without a strong justification. > > Because I was told by you that "Generating a lot of output for the oom > reports has been a real problem in many deployments.". > Maybe I misunderstood you : ( I meant to say that we do not want to add more output unless there is a real need. Changing the existing output is usually tricky because there are existing parsers that might break on that change. Not that we do guarantee the output format officially but we try hard to preserve as much as we can if that is possible. That being said maybe the lack of reclaim guarantee information is a more wide spread problem and more people are suffering from it. If that is the case then the justification would be much easier to formulate. -- Michal Hocko SUSE Labs