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 8329EC4167B for ; Wed, 29 Nov 2023 00:34:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1372D8D0017; Tue, 28 Nov 2023 19:34:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E7CD8D0001; Tue, 28 Nov 2023 19:34:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF0C98D0017; Tue, 28 Nov 2023 19:34:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DFA8C8D0001 for ; Tue, 28 Nov 2023 19:34:53 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B5589802A5 for ; Wed, 29 Nov 2023 00:34:53 +0000 (UTC) X-FDA: 81509121666.06.509DB8E Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) by imf23.hostedemail.com (Postfix) with ESMTP id A287714000E for ; Wed, 29 Nov 2023 00:34:51 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hCs4fXYa; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.171 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701218092; 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=eCG5NdHCzdxGKVLi7pGKuTOz+k6jebi5zet5ZX/JZ48=; b=RWWUWX126yJn6Nzy50/mbFoDyputo7fUibIzUdW4b79AvD8p9JPmtYmietoHzLDxat+1LH PgL/wofhHO5R7NXajvJ+U0s35GJjuUIPxHN4T2x67sYB+R8mrKhAGdYO1EbWrXV79YZlk7 qaSy73qVJN67r15vULHj8qZl7C37FA8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=hCs4fXYa; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf23.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.171 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701218092; a=rsa-sha256; cv=none; b=1pEkyT/vM9/cPfMXhn+lH4qIzk3qY86eASh7AT0Dnm9Xi3nqdu1KaXoig7yiaOFKjJ507z yw5KwgSKXpl+GGCOrjKkU2L4K8eOK8tng725PLsph2WipFFFLTLrM/Xr0Soh0GbxT9SKIz 65jwoimNBnlNj3MuQSChCs0Q7MmJiXY= Date: Tue, 28 Nov 2023 16:34:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1701218089; 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=eCG5NdHCzdxGKVLi7pGKuTOz+k6jebi5zet5ZX/JZ48=; b=hCs4fXYaAgMAWKjmXvNJIPSN4wz1/xn8Hyz7XcidRcR5ozIfrhEmkmovPoPbatOFeyi0sR f5cLYwhH4ikIcioHBYBkI7vKoibpemOsxn9lz03kIJKOsQT9Qe4lcri3b5Zvuiw3zpxZSV NMtLh8oxUJgEibrBLVOJwAD1owi6AO8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Qi Zheng Cc: Kent Overstreet , Muchun Song , Linux-MM , linux-kernel@vger.kernel.org, Andrew Morton , Dave Chinner , Michal Hocko Subject: Re: [PATCH 2/7] mm: shrinker: Add a .to_text() method for shrinkers Message-ID: References: <20231122232515.177833-1-kent.overstreet@linux.dev> <20231122232515.177833-3-kent.overstreet@linux.dev> <20231123212411.s6r5ekvkklvhwfra@moria.home.lan> <4caadff7-1df0-45cc-9d43-e616f9e4ddb3@bytedance.com> <20231125003009.tbaxuquny43uwei3@moria.home.lan> <76A1EE85-B62C-49B3-889C-80F9A2A88040@linux.dev> <20231128035345.5c7yc7jnautjpfoc@moria.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A287714000E X-Stat-Signature: rsca8fc1i679aeajk68im745zc1n7acp X-HE-Tag: 1701218091-220519 X-HE-Meta: U2FsdGVkX19y7qXDe5e8wELrGK+REOVtyTiRXGs+LMu7AgXvcznyhackf/rOsuYktjtSPQpwD2JJcIt1IxeVWngCpZDv6xwAqAhTwOVg3sjMM4S1BdYw2NKqvzfAty8sSlMmDb2U5EzjYOg/5kWnms056TtNVBq4x0V7mQWarW/tbhVJXIWLskQYwdnBKzTXedpDthjFjabJOh4FPpWUbCFCdWCEU381yVNXldnfuCJra+0p6QOtHTMZaNPnmqVEb7GGgNK+O3JsgMFEf0DHNil7oVCRQfodjVVCccWBomgHyiIClNS+YTi9Ady4648nYCsHrL6gcjUA5RHcmaYvtIwIvqbwGMPxr/eam/CS05D+XxLeUwquhWiZ+WyRBmTFTpGFwgyWjnFCbpNg/rRv/X/0Ehp4UfwomJ7OQG0M5BFxMzu3Ge0imNB4mkRoG2sReXWPBMzjMBfVYNs62wk62RxcGqyofuMbHud/bPrLe5++j7gIZIrris+czoX7ms7hfds8o4FcCL/uSPuP/EPhnq+kHHkWm87u3Fn7DbVgwpZ9znMpzOGNEXrCdM1zHsCL/lOJdZRbS+CI7H6bs5lXJYsyNHrUnXqfCihKvEBp0p/NSPouuFUXiJziMmEM6VXnIGljD9Tr076sLkYDQth5uxkbYdPHnitfz3PkJHc/9jH/LJTYq5NzZErC1NP/p1eqRzEkUiJytw1+jwDp+hTh0kUbc2x1r4u3Vud80B5UtkvBRhEJcl94a6isK7VLM+XSVh0Srkz0RDaVkg/O5wQ84fTUEC7nMZKk71XsYMIqFPlXwh2BQTwOcoGrSak3HHFDJIh+s371hqtzfEN0IoyoAzC6EPNuv7SXPHPhj+bLOEQK6zPgPF4LvLSrX9IT1buz2eRnEWxC+bxq5FEH6TGPItjC2r4eJHMlVUrMAeeZwJstQ1TZXgElm//IWxFcUb/BP41wQZxNadwk3yJWiSd f2UCvbfl 9PlgvDBcSPIbRFpofkVou71POdSd4RZxvQNzeBX2ZmGYpsoAyaBtbXFIjwh68EJeNEH2PYECLdaztyo3M/pzBYeF0H4eqAwRA83fT0kTCVo4G/8OiOoMsot2AuItASvBQ1Ut1RQRS9rhnufHJ9ytrGR2XNYDZ5kDKU9W+9ZYg0lbasariPll5sLwkCA== 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 Tue, Nov 28, 2023 at 02:23:36PM +0800, Qi Zheng wrote: > > > On 2023/11/28 11:53, Kent Overstreet wrote: > > On Tue, Nov 28, 2023 at 11:27:11AM +0800, Muchun Song wrote: > > > > > > > > > > On Nov 25, 2023, at 08:30, Kent Overstreet wrote: > > > > > > > > On Fri, Nov 24, 2023 at 11:08:11AM +0800, Qi Zheng wrote: > > > > > Hi Kent, > > > > > > > > > > On 2023/11/24 05:24, Kent Overstreet wrote: > > > > > > On Thu, Nov 23, 2023 at 11:32:59AM +0800, Qi Zheng wrote: > > > > > > > > + void (*to_text)(struct seq_buf *, struct shrinker *); > > > > > > > > > > > > > > The "to_text" looks a little strange, how about naming it > > > > > > > "stat_objects"? > > > > > > > > > > > > The convention I've been using heavily in bcachefs is > > > > > > typename_to_text(), or type.to_text(), for debug reports. The > > > > > > > > > > OK. > > > > > > > > > > > consistency is nice. > > > > > > > > > > However, this is inconsistent with the name style of other > > > > > shrinker callbacks. Please use the "objects" suffix. As for > > > > > bcachefs's own callback function, you can use typename_to_text() > > > > > to ensure consistency. > > > > > > > > That would be inconsistent with introducing a convention to the wider > > > > kernel. > > > > > > > > > > I don not think .to_text is a good name. I really do not know what it means > > > when I first look at this name. I knew you want to report the objects of > > > shrinks, so why not use .report_objects or stat_objects proposed by Qi. > > > Although .to_text is only used by bcachefs now, shrinker is a general module > > > which is not only serving the bcachefs itself. I think it should be better > > > to use a more straightforward name. > > > > No, .report_objects or .stat_objects would be wrong; this isn't > > generating a report on the objects owned by the shrinker, it's just a > > report on the statistics of the shrinker itself. > > Now I think adding this method might not be a good idea. If we allow > shrinkers to report thier own private information, OOM logs may become > cluttered. Most people only care about some general information when > troubleshooting OOM problem, but not the private information of a > shrinker. I agree with that. It seems that the feature is mostly useful for kernel developers and it's easily achievable by attaching a bpf program to the oom handler. If it requires a bit of work on the bpf side, we can do that instead, but probably not. And this solution can potentially provide way more information in a more flexible way. So I'm not convinced it's a good idea to make the generic oom handling code more complicated and fragile for everybody, as well as making oom reports differ more between kernel versions and configurations. Thanks!