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 45E6CC07CA9 for ; Thu, 30 Nov 2023 19:01:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3CA66B0476; Thu, 30 Nov 2023 14:01:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CEC276B0477; Thu, 30 Nov 2023 14:01:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BDAE66B0478; Thu, 30 Nov 2023 14:01:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id ACFC66B0476 for ; Thu, 30 Nov 2023 14:01:37 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3B0A71C0322 for ; Thu, 30 Nov 2023 19:01:37 +0000 (UTC) X-FDA: 81515539434.13.421E8B7 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf16.hostedemail.com (Postfix) with ESMTP id 38EFF180038 for ; Thu, 30 Nov 2023 19:01:29 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=EKSS4CpU; spf=pass (imf16.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=roman.gushchin@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=1701370890; 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=Wjwn+GK6+t6wHRxnzMCcBASuxxo0/IKSxDYD1mPq7Mk=; b=Rih3Ce9IOF5r3xKt2PRcyVkC5gwXvYqQWWNZtQO6Yom0fEvQegEHNkOKdnVpPIvXOTqwey 4Fd5X8Uc9FCk5Wu/7qfbqL610sOZ8fApMZxeH4EdedYIF1Dwx7oKTQMKbtZafIJgq1vQ3H 5nAFL98vUtuzAcfHz4VzqsfX+JgmRq0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=EKSS4CpU; spf=pass (imf16.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701370890; a=rsa-sha256; cv=none; b=bq3aGowzRWZD2AanzYzTpHvvqKHOybme4AyWPqI3LFI42q28WpLFTDn7iB/42gNn1ZKzXx xu28p6zeqN/87g/fJOBlp0kh4/X0T1PYPMFEr9ocwPCN/ltw2/gYOtmVsCYs3oqgcKCmrD PvOAMxDXVmpB1TREsCUWga2gqvuNX3I= Date: Thu, 30 Nov 2023 11:01:23 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1701370887; 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=Wjwn+GK6+t6wHRxnzMCcBASuxxo0/IKSxDYD1mPq7Mk=; b=EKSS4CpU+3PlEbw2J5W6+TxNZqFWLJRQGEd1fVvrHDcrjv4YNRLFuww9WpM5h1n8IHofKu NkcFMFZHQyOyLbYq66cIkwXY4dvDrADd8RrJS/PYfJOavKpGwrSSbzqWaW6TDkQo+16c4S IhcbpUjwnx2jGQ1T9OcIWa7INtfxc7c= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Kent Overstreet Cc: Qi Zheng , Michal Hocko , 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: References: <4caadff7-1df0-45cc-9d43-e616f9e4ddb3@bytedance.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231130032149.ynap4ai47dj62fy3@moria.home.lan> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 38EFF180038 X-Rspam-User: X-Stat-Signature: mxn5gq1u5169bcymx4jjqpkadqnkf9z4 X-Rspamd-Server: rspam01 X-HE-Tag: 1701370889-889483 X-HE-Meta: U2FsdGVkX190W1sfBkcBfaYnG1lk76zeR31v0K1Nw9yZht+U+LzxUJzT62jy9lrAL2VIMR0TqeW4z5UMvfUeVxc6UtpB0qMGqKYTKW8g9dHcStM33paWVBxAydXGFCQ2wnLj3SvDrlMefHJLM++2J1tYPZoJ+8ttK6moAe9ya92kpRmbhBxLpXhcBPkjJ2rKW8/Vi2i8/mzdBFTvZxgYs+XxeNVTx1Uk1JsGkNSBHyfMwge5TYkG1P0RYdbJsF3EGHoOub4Jp0FBmr6ytsCPLFCUWh+PY2HRvR0Keq66QgsK6y37suDKzyhNz/LyGDMLqxs02ZH7SL8lUMu18ukV8dCBWi51bu28oxW8Zwm3TFxqP6hcfwjK4Uaep8AvkmYdnSfbp93tlIMb5EZsBpDEse9IN+Xfo4LktZh6EQSr3OoL9dn5vK/fwozr+Mg0Qz3ct6rjaaj0WJGcCeGmJsrRmfv9fLg64BNK1GPC3b3DbyUj1EVI0TwNDsAqGQMKAXd7+UajeotXwZ6seMqxDF+VT9CX3vM7bpLVdbeDDXjEzcZ4is5fSfSqjU3PwS5De5VmjcWbk4Wn6Mzo7eE18QODqFWJ0ynIwEPDTWHqcqKX77I304ff4hXViLnZpDTXXZFeqQRADzZxTjjaIs3IEWFIdQcdAuiygp8lZgplXbo+3pnDuppkEGXu49o224Krwo09lFISADL9QpbsadTtPaXOnYY/BhQh3bGKsV0nEIqNRwv83rhzrGT7rYeEa8nKXqp44i1mtyNjvc3j7f+nxjTsjJ1KnwJgwjHbWDBdy8GwdkjPMFHpAn1fX7elqEMA64tVcJ11U972y10ScB0AGlLhG2KxcbTl5/ALCxSw69FQbstXvBcEGLr7OJGPAthHyYhFLzyao5GALcLqmDCQWh5n4Si3Hs5jqT22CS8a/oaxT+S6ojfTR+6V0q4EMHbbKfDZQ7/9zWKPeQOLsrU+ilJ 5cgnjhQ/ ZpRdRDVT/WwmGmSrmXzGfcz3vjLAEpFpvAAaQjVyLDhSUCTCfQ8Wpbo/HfRPqNYH561rBnnFYOIx8NUn4c3Lb/OmeFpUz37Fzxn1V4l+26l2cceHUICG+7xmM+hzcHa6V+NW/E8IRYQtVt/C2hzUcolT0Oh+GgpOVSz6WsnVtGhH0CYBVQzogIOrC3z9/8VrugmlMMEky8TWM+j5YFBWeioKCOSp5Yyg4SUSWuNSN1qDmhWlJ8rwgb23ngg== 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 Wed, Nov 29, 2023 at 10:21:49PM -0500, Kent Overstreet wrote: > On Thu, Nov 30, 2023 at 11:09:42AM +0800, Qi Zheng wrote: > > > > > > On 2023/11/30 07:11, Kent Overstreet wrote: > > > On Wed, Nov 29, 2023 at 10:14:54AM +0100, Michal Hocko wrote: > > > > On Tue 28-11-23 16:34:35, Roman Gushchin wrote: > > > > > On Tue, Nov 28, 2023 at 02:23:36PM +0800, Qi Zheng wrote: > > > > [...] > > > > > > 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. > > > > > > > > Completely agreed! From my many years of experience of oom reports > > > > analysing from production systems I would conclude the following categories > > > > - clear runaways (and/or memory leaks) > > > > - userspace consumers - either shmem or anonymous memory > > > > predominantly consumes the memory, swap is either depleted > > > > or not configured. > > > > OOM report is usually useful to pinpoint those as we > > > > have required counters available > > > > - kernel memory consumers - if we are lucky they are > > > > using slab allocator and unreclaimable slab is a huge > > > > part of the memory consumption. If this is a page > > > > allocator user the oom repport only helps to deduce > > > > the fact by looking at how much user + slab + page > > > > table etc. form. But identifying the root cause is > > > > close to impossible without something like page_owner > > > > or a crash dump. > > > > - misbehaving memory reclaim > > > > - minority of issues and the oom report is usually > > > > insufficient to drill down to the root cause. If the > > > > problem is reproducible then collecting vmstat data > > > > can give a much better clue. > > > > - high number of slab reclaimable objects or free swap > > > > are good indicators. Shrinkers data could be > > > > potentially helpful in the slab case but I really have > > > > hard time to remember any such situation. > > > > On non-production systems the situation is quite different. I can see > > > > how it could be very beneficial to add a very specific debugging data > > > > for subsystem/shrinker which is developed and could cause the OOM. For > > > > that purpose the proposed scheme is rather inflexible AFAICS. > > > > > > Considering that you're an MM guy, and that shrinkers are pretty much > > > universally used by _filesystem_ people - I'm not sure your experience > > > is the most relevant here? > > > > > > The general attitude I've been seeing in this thread has been one of > > > dismissiveness towards filesystem people. Roman too; back when he was > > > > Oh, please don't say that, it seems like you are the only one causing > > the fight. We deeply respect the opinions of file system developers, so > > I invited Dave to this thread from the beginning. And you didn't CC > > linux-fsdevel@vger.kernel.org yourself. > > > > > working on his shrinker debug feature I reached out to him, explained > > > that I was working on my own, and asked about collaborating - got > > > crickets in response... > > > > > > Hmm.. > > > > > > Besides that, I haven't seen anything what-so-ever out of you guys to > > > make our lives easier, regarding OOM debugging, nor do you guys even > > > seem interested in the needs and perspectives of the filesytem people. > > > Roman, your feature didn't help one bit for OOM debuging - didn't even > > > come with documentation or hints as to what it's for. > > > > > > BPF? Please. > > > > (Disclaimer, no intention to start a fight, here are some objective > > views.) > > > > Why not? In addition to printk, there are many good debugging tools > > worth trying, such as BPF related tools, drgn, etc. > > > > For non-bcachefs developers, who knows what those statistics mean? > > > > You can use BPF or drgn to traverse in advance to get the address of the > > bcachefs shrinker structure, and then during OOM, find the bcachefs > > private structure through the shrinker->private_data member, and then > > dump the bcachefs private data. Is there any problem with this? > > No, BPF is not an excuse for improving our OOM/allocation failure > reports. BPF/tracing are secondary tools; whenever we're logging > information about a problem we should strive to log enough information > to debug the issue. Ok, a simple question then: why can't you dump /proc/slabinfo after the OOM? Unlike anon memory, slab memory (fs caches in particular) should not be heavily affected by killing some userspace task. Thanks.