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 402A9C10DCE for ; Fri, 1 Dec 2023 21:25:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81FD16B0346; Fri, 1 Dec 2023 16:25:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CE956B04FE; Fri, 1 Dec 2023 16:25:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6BE446B04FF; Fri, 1 Dec 2023 16:25:19 -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 5D78D6B0346 for ; Fri, 1 Dec 2023 16:25:19 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 266CC160325 for ; Fri, 1 Dec 2023 21:25:19 +0000 (UTC) X-FDA: 81519530358.08.99A36D1 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) by imf14.hostedemail.com (Postfix) with ESMTP id 33358100017 for ; Fri, 1 Dec 2023 21:25:15 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="gc6yl/zt"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701465917; a=rsa-sha256; cv=none; b=d0lS1Z8g6yUgUKd11Obv3N246DD7kb0Jdda8lho3W5K7nrgW7FXsfvkMfRBpaYVzHDSszQ hcNeHTm6lJAiIDp0p3QUY/DXToXNIjxainGl6GrunBE+pdFxNIfHwQT4axr6i9uOJFpBUo g1XPP2k8Lzfi3s12dq0RNETlYZyBRjQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="gc6yl/zt"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf14.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701465917; 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=YSgoe7iZYKiPM6BcayB3V39+srzlSNOnYElv/By5ffY=; b=gqzh+obufVpRTsQthYjC4AgA9NvUxEzncDBKzzT0B3kNKJbGeLD9WQtjKRw48sG+bDaxs5 8XYHa2MlsA6uKpIr8qUfrCKxKv0lbBhReTFMX8tV4Q5C/hYQryEWRRZGdiiVi3C/nN0Mex yyek3oGS1AhVCTFF0r3TL+qcTJM0KFI= Date: Fri, 1 Dec 2023 16:25:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1701465910; 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=YSgoe7iZYKiPM6BcayB3V39+srzlSNOnYElv/By5ffY=; b=gc6yl/ztFUNQwfobq42K6NCtYZpPRWQcxOzOmE7jxwtoeLHyrvyMd+3AawaE+RRDfsI+oa x1nSJ9mFZ06h1JB/74dFCH94XCysnPMjaOJvykGEEygt3xpwKrkU386cB3+AAuje8cgRk1 pKuqNn/erKapz5JzDwV9+5fVCMmiyos= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko Cc: Roman Gushchin , Qi Zheng , 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: <20231201212506.skgzaoafi5zgi3pi@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> <20231201014745.b2ud4w3ymztdtctu@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: rspam06 X-Rspamd-Queue-Id: 33358100017 X-Stat-Signature: x3z55jfqh4hdoo5oru3h98igi916n6ga X-HE-Tag: 1701465914-856909 X-HE-Meta: U2FsdGVkX18XEfJrO3/QcOZh9CHT8RHhYUHqR2VPA1uaR0++SMl/fSkP+iSDksJIzxYRWKuqHgh73GV9bZGZlt/vCwPMn/mMj1Nz120iVXwDAgv/NqyiU+BZ7JETUiLMIUI4/xtKukSZBeysMnUetoMZLJ4o/iF8lERwlGOLxEWev48D0+EcVTwn97FSNk1uSwvFzxDGHGcBjQItbWVFOyGItivNjbAVx01mGAiE7UmQpZvEeXNb53AB6xLuBWsvMIzQzYD2Vz1ffXaz0VzA6hoIqnZwWRmJzpExUjri19TKEbfnT1WYs5h0n9W9Si5Xhb9mswkUQPzJsO7vR5dAjbNtHwSW4i/04ZKgOKCKUHR7v+M/BYFekIurHv2fFDiC9qBmp6sGlYF96YOQCWdbevl2ZsE4d10nyJiTmv6E7JYrOdGg5jvjJeDqUvH3fAK6m+O5YU2A525UAKsKWVn8F0BYOqAt7LXQDtxKch0Rgaro1C/IvetX4cPpuRGZQBFyrjEep98R/WTHQxLoiofuFc1Le+wxUGBt73SgbKIUyl8RDPgzudxtOegoRxdnX4h3Mj4dpl/2ac3WZv+CtL1LEX4iRdk7K9DW1aLukBQitmp7sZUugqT5WaWaVrplAhdQp84O1YEGmRVPB1sB7KOONvsDykPh9R3OytOGigLuQaY3TRnjNv09wosOH9Ibt4FXTAkejczZCVLnpVZwCfa/FTwY1Si147szZ1Whs1qrw5I4pSzavCflZUJlri93Xf0ekMMRzra8Yb6sIJ9T40dbhJbK96iKfqigXUy13hK5yglpyGgWeSCZLcgFxRV2rpUlDGtWJVSVOA4vsSAR8xIT2msu6caATsLfGJTmjlwHGPa0Utsuhcy2F399eF9vQQpgCCRKD9NkERDVdsI69J33C11kmi26bWaMmnhpZUast8QiBBiCG1SN0LkU1YlQ3BUGVm8cP3Tx7ej33qfR2/Q z0+ipNoK l/2JQggXn5p4O18uY7WKoc4tWI6TWGGrQFPoxtRH6XC4SbNO5BtXXY9SQVKsWEm7si4Av0bXwqrBrxXrvANhxG1IOx/k4GpEWI0ZJ 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 Fri, Dec 01, 2023 at 11:04:23AM +0100, Michal Hocko wrote: > On Thu 30-11-23 20:47:45, Kent Overstreet wrote: > > On Thu, Nov 30, 2023 at 09:14:35AM +0100, Michal Hocko wrote: > [...] > > > All that being said, I am with you on the fact that the oom report in > > > its current form could see improvements. > > > > I'm glad we're finally in agreement on something! > > > > If you want to share your own ideas on what could be improved and what > > you find useful, maybe we could find some more common ground. > > One thing that I would consider an improvement is to have a way to > subscribe drivers with excessive memory consumption or those which are > struggling to dump their state. Remember the memory allocation profiling patchset? The one where you kept complaining about "maintenancy overhead"? We can plug that into the show_mem report too, and list the top 10 allocations by file and line number. > Maybe your proposal can be extended that way but the crucial point is to > not dump all sorts of random shrinkers' state and end up with unwieldy > reports. If, on the other hand, any particular shrinker struggles to > reclaim memory and it is sitting on a lot of memory it could be able to > flag itself to be involved in the dump. Great, since as was mentioned in the original commit message it's not "all sorts of random shrinkers", but top 10 by objects reported, what I've got here should make you happy.