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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88DA4C433F5 for ; Fri, 22 Apr 2022 10:51:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEDE46B0074; Fri, 22 Apr 2022 06:51:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9D786B0075; Fri, 22 Apr 2022 06:51:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C651A6B0078; Fri, 22 Apr 2022 06:51:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id B36746B0074 for ; Fri, 22 Apr 2022 06:51:14 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 78C97121136 for ; Fri, 22 Apr 2022 10:51:14 +0000 (UTC) X-FDA: 79384198068.31.920D38D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf04.hostedemail.com (Postfix) with ESMTP id BA1AA40028 for ; Fri, 22 Apr 2022 10:51:11 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id EBE4221117; Fri, 22 Apr 2022 10:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1650624670; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Fv37HN/IG+2L97s4FB5ttyXca0ZiVPK46/Rpu1Qgni4=; b=q7Lkt4GhhESuKQ4uT9G4GtLC+qxyCW9i7CpwIlBxIT/kjQ1cuuE6Ps9M0OYUCgUkKCBfuM M9zka9w+hOZy72mZsRSZ4BOWroNAOraJP7+TZTnh7szAI1UUk+ddEYS0rYGzxC5spZARTO 0KJetR3dB9IIheo2NvH31eMCrBBH9eY= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A0A682C149; Fri, 22 Apr 2022 10:51:10 +0000 (UTC) Date: Fri, 22 Apr 2022 12:51:09 +0200 From: Michal Hocko To: Kent Overstreet Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, roman.gushchin@linux.dev, hannes@cmpxchg.org Subject: Re: [PATCH 3/4] mm: Centralize & improve oom reporting in show_mem.c Message-ID: References: <20220419203202.2670193-1-kent.overstreet@gmail.com> <20220419203202.2670193-4-kent.overstreet@gmail.com> <20220420165805.lg4k2iipnpyt4nuu@moria.home.lan> <20220421184213.tbglkeze22xrcmlq@moria.home.lan> <20220422083037.3pjdrusrn54fmfdf@moria.home.lan> <20220422094413.2i6dygfpul3toyqr@moria.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220422094413.2i6dygfpul3toyqr@moria.home.lan> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BA1AA40028 X-Stat-Signature: 9dx3617bhfjwn9oaswkrx9bqfezpwb8q Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=q7Lkt4Gh; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1650624671-252977 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 Fri 22-04-22 05:44:13, Kent Overstreet wrote: > On Fri, Apr 22, 2022 at 11:27:05AM +0200, Michal Hocko wrote: > > We already do that in some form. We dump unreclaimable slabs if they > > consume more memory than user pages on LRUs. We also dump all slab > > caches with some objects. Why is this approach not good? Should we tweak > > the condition to dump or should we limit the dump? These are reasonable > > questions to ask. Your patch has dropped those without explaining any > > of the motivation. > > > > I am perfectly OK to modify should_dump_unreclaim_slab to dump even if > > the slab memory consumption is lower. Also dumping small caches with > > handful of objects can be excessive. > > > > Wrt to shrinkers I really do not know what kind of shrinkers data would > > be useful to dump and when. Therefore I am asking about examples. > > Look, I've given you the sample That sample is of no use as it doesn't really show how the additional information is useful to analyze the allocation failure. I thought we have agreed on that. You still haven't given any example where the information is useful. So I do not really see any reason to change the existing output. > output you asked for and explained repeatedly my > rationale and you haven't directly responded; Your rationale is that we need more data and I do agree but it is not clear which data and under which conditions. > if you have a reason you're > against the patches please say so, but please give your reasoning. I have expressed that already, I believe, but let me repeat. I do not like altering the oom report without a justification on how this new output is useful. You have failed to explained that so far. -- Michal Hocko SUSE Labs