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 8686CC433FE for ; Fri, 22 Apr 2022 12:58:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2642A6B008A; Fri, 22 Apr 2022 08:58:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C7F76B008C; Fri, 22 Apr 2022 08:58:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F31326B0092; Fri, 22 Apr 2022 08:58:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id D63356B008A for ; Fri, 22 Apr 2022 08:58:21 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B0C3A3F5 for ; Fri, 22 Apr 2022 12:58:21 +0000 (UTC) X-FDA: 79384518402.06.01CDAB5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf27.hostedemail.com (Postfix) with ESMTP id 1F6F440036 for ; Fri, 22 Apr 2022 12:58:20 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id DB2B41F37F; Fri, 22 Apr 2022 12:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1650632299; 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=ttueTufraI8o+nOH58tUB2QJPrzh4JNYOp+IJirkuvA=; b=YT4zeOCamq4IRrxGBDYOeDUQRJJaxapLMlJ2EGoaucQjpphuIf/+yafGsEdXPff4s31Lp2 8FbOPH0RgFB2x89OTcLwqnfaCb1Mobh4Qf3O086ueI5IJnODHS7kkU8fpeZHLOAOa+Cx/5 nHqMLobx1WdUD1azZx6Zzyru/glg+A0= 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 A5FAB2C142; Fri, 22 Apr 2022 12:58:19 +0000 (UTC) Date: Fri, 22 Apr 2022 14:58:19 +0200 From: Michal Hocko To: Kent Overstreet Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hch@lst.de, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-clk@vger.kernel.org, linux-tegra@vger.kernel.org, linux-input@vger.kernel.org, roman.gushchin@linux.dev Subject: Re: [PATCH v2 8/8] mm: Centralize & improve oom reporting in show_mem.c Message-ID: References: <20220421234837.3629927-1-kent.overstreet@gmail.com> <20220421234837.3629927-14-kent.overstreet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220421234837.3629927-14-kent.overstreet@gmail.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 1F6F440036 X-Stat-Signature: c9w48deazji5mj49gawpncwrcxir5mnd Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=YT4zeOCa; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-HE-Tag: 1650632300-102882 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 Thu 21-04-22 19:48:37, Kent Overstreet wrote: > This patch: > - Changes show_mem() to always report on slab usage > - Instead of reporting on all slabs, we only report on top 10 slabs, > and in sorted order As I've already pointed out in the email thread for the previous version, this would be better in its own patch explaining why we want to make this unconditional and why to limit the number caches to print. Why the trashold shouldn't be absolute size based? > - Also reports on shrinkers, with the new shrinkers_to_text(). > Shrinkers need to be included in OOM/allocation failure reporting > because they're responsible for memory reclaim - if a shrinker isn't > giving up its memory, we need to know which one and why. Again, I do agree that information about shrinkers can be useful but there are two main things to consider. Do we want to dump that information unconditionaly? E.g. does it make sense to print for all allocation requests (even high order, GFP_NOWAIT...)? Should there be any explicit trigger when to dump this data (like too many shrinkers failing etc)? Last but not least let me echo the concern from the other reply. Memory allocations are not really reasonable to be done from the oom context so the pr_buf doesn't sound like a good tool here. Also please make sure to provide an example of the output and _explain_ how the new output is better than the existing one. -- Michal Hocko SUSE Labs