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 369CBC4167B for ; Thu, 30 Nov 2023 04:14:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B18FD6B043A; Wed, 29 Nov 2023 23:14:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ACA706B043B; Wed, 29 Nov 2023 23:14:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 991DA6B043C; Wed, 29 Nov 2023 23:14:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 859506B043A for ; Wed, 29 Nov 2023 23:14:53 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2ED58C0687 for ; Thu, 30 Nov 2023 04:14:53 +0000 (UTC) X-FDA: 81513304866.24.11C2AEA Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) by imf06.hostedemail.com (Postfix) with ESMTP id 33675180013 for ; Thu, 30 Nov 2023 04:14:50 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=p7G7lo0f; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701317691; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sOgwC1NdimlzYQo5Epj8cIIpO4bimXE0tJXhrILlqsg=; b=VcfT7fnXhf36PwX5Vpdh1xZQTVTxVAdkKeW9pZPmkArvWwEtueS7Nvo2apWoVSOA9X8X0a NyRY0uW6GqERHrYx1iTl4cbqUubcLQGp6jcx95A8ccXGDsZzzsk5qUziuHuO5RNQYWykHD roVlD1UhixtzOGnoLlJCVdGgv4ZjYzU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701317691; a=rsa-sha256; cv=none; b=2lgTEaRriBGDMKjUS13OzPLpmka+6T7ftRf4lqglrKnH9F+G/ZmOcPOOFEBbaSAxSRUb/s YjSVeFJMUciOQsaV7nrLH6fn2b4wTd5dysEZuYgxEuUcyKPzgOa1YNElL+YjuEUL5ALznP 9wIUkIsgcvNRvJOQbNTCirS9nOv8HBE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=p7G7lo0f; spf=pass (imf06.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.175 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 29 Nov 2023 23:14:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1701317689; h=from:from:reply-to:subject:subject: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=sOgwC1NdimlzYQo5Epj8cIIpO4bimXE0tJXhrILlqsg=; b=p7G7lo0fSJvxUHk9qub8yOk3MjGHq4JEevY4ZI5IXmIyT9FmJ+3NqAplpxnqSQI7KOLWEI 6mbt+WSLPiFiTnG1UpmmrhgPlCS2tWwqxcbP6ncDFFidF8b747d1cqP8Nxy/OaBkK2LtuR nTAtfwpyT2DAM9rK/gXBm2WVDnpY77E= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Qi Zheng Cc: Michal Hocko , Roman Gushchin , Muchun Song , Linux-MM , linux-kernel@vger.kernel.org, Andrew Morton , Dave Chinner Subject: Re: [PATCH 2/7] mm: shrinker: Add a .to_text() method for shrinkers Message-ID: <20231130041444.7cbhbvkvwpcbbhyd@moria.home.lan> References: <20231125003009.tbaxuquny43uwei3@moria.home.lan> <76A1EE85-B62C-49B3-889C-80F9A2A88040@linux.dev> <20231128035345.5c7yc7jnautjpfoc@moria.home.lan> <20231129231147.7msiocerq7phxnyu@moria.home.lan> <04f63966-af72-43ef-a65c-ff927064a3e4@bytedance.com> <20231130032149.ynap4ai47dj62fy3@moria.home.lan> <6f56c8f4-77e3-4ad7-a5f8-a6235b047137@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f56c8f4-77e3-4ad7-a5f8-a6235b047137@bytedance.com> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: anped1d45ab67fkffacb548btroq6d59 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 33675180013 X-Rspam-User: X-HE-Tag: 1701317690-99309 X-HE-Meta: U2FsdGVkX1/EfGkfmKQaJuOOoQ1LCbxLWOgMWytXKCBnYEgJkPyQDAwn1xIyJQjafDpF+Hd1oTppILbm+GQb3UmmwHxukD1R/RkuSV8VWsHLj+ur7aT2HxQgdvVEsMPaxRT5/RlPX7ytx8dM2qKrGJnQ5m67mScaoYAX4j5OXkM7mMIF+SHypwbCok9KfCJsiSK/8MwTwxMOl+Fd8wjF27iSr4bODdO0XuCVnhyzpBI5SRZ+okB2I4CDV/0SsyidGxwQkVSdIRut0P9hYDrRLo8Qnz4+r6xP/1XqOaXG3MBqhtWOKA+gh+Xf00x8BoTS6+YUsoGY0cou/m+pPRzwq96g5cRlBzgvfDRAkugsa6mtkZx2PZgwItR7T+r8Eqk1lxFlwdXliEhcfJCZ45T/eqOsqWzfCB7UoAwQLCS82sG+nBhkCmRqg34R8qOm0mzBJm5ybk9kO48KKM2DzZDeH1CucK6GB3d9+n8xFaLn3kWKv1TDCA8D/GZ3xs5PGedB/V2kVUFfZb2OjH37fgP8ybmGCq4L8yN2UDFD1+7PAD0HfMa52sXwUB/5gjl85uzs8CLVxvCSbMfjHp/nQR3IIHMYe+vsLpsnrVK30EyzlQCLKip/xiVxMNklpjIV20y+akSIe+lYZHq72t+8ckpejID0i/RNSdEhFCHp9vaUtczbCj/pd9obnYLeSbwDsp6lu93+HniY5gnns1CLw1H2RXpCdOf0ndqVfg95uwHIZZCkBuH3gUEIToC+pCwy0mtlFoIaP1eOA/9C7QEnwgnApaNM7GCfu+r0Tn75K7b8WB13O3Hqr/LMaBlX5jYc3oinMJqqFLPISn3Is8cU+jXn1DkuVWs3C/Ser58eXNbRuPOuvpx617JaGHRMq9AY0Ckkke8ee7AzyfYACCpzeL4IlGgHDMcAFtu5rl06Ve/HFq8zK0d0XxWD4cLAZOXjLgYrFOPIVMtXh4NQa5SpHCw eAQVnXNU +4kj555Wcn0q6DabOVOe7CIK1hcyRFBWZ5tlqzK4Les5kW1jElm1LwJhrOkAatVaaWenwmqw4xZ39TVZXRTAXMWPTxoMQc4IA+cI9 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 30, 2023 at 11:42:45AM +0800, Qi Zheng wrote: > > Similarly for shrinkers, we're not going to be printing all of them - > > the patchset picks the top 10 by objects and prints those. Could > > probably be ~4, there's fewer shrinkers than slabs; also if we can get > > shrinkers to report on memory owned in bytes, that will help too with > > deciding what information is pertinent. > > I'm not worried about the shrinker's general data. What I'm worried > about is the shrinker's private data. Except for the corresponding > developers, others don't know the meaning of the private statistical > data, and we have no control over the printing quantity and form of > the private data. This may indeed cause OOM log confusion and failure > to automatically parse. For this, any thoughts? If a shrinker is responsible for the OOM, then that private state is exactly what is needed to debug the issue. I explained this earlier - shrinkers can skip reclaiming objects for a variety of reasons; in bcachefs's case that could be trylock() failure, an IO in flight, the node being dirty, and more. Unlock the system inode shrinker, it's much too expensive to move objects on and off the shrinker list whenever they're touched. Again, this all comes from real world experience. The show_mem report is already full of numbers with zero explanation of how they're relevant for debugging OOMS; we really need to improve how that is presented as well.