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 0F082C4167B for ; Tue, 5 Dec 2023 08:49:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 623E76B007E; Tue, 5 Dec 2023 03:49:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D4266B0080; Tue, 5 Dec 2023 03:49:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C36B6B0081; Tue, 5 Dec 2023 03:49:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3CB236B007E for ; Tue, 5 Dec 2023 03:49:20 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 11F9416023C for ; Tue, 5 Dec 2023 08:49:20 +0000 (UTC) X-FDA: 81532140480.16.F950982 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf26.hostedemail.com (Postfix) with ESMTP id DCAE9140008 for ; Tue, 5 Dec 2023 08:49:17 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ciI7k1Ia; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701766158; 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=9sZvp0Yv4XmHqd7T+QuGS//57nbANCXbTnNouufMNFk=; b=e9ccodrX14NHzeaDxbDOTYx7Rhw9SY6tKSVWvD+f0Y39RVyv060v33yqdY7HREclal8SQd XapekCmgP6ySnlwbKEdaEug27mDdjUesht3XP1qkKqfhaL0QCdeLBw6nMk7woNUChFe4eC +EY3YXmA+Cm6yKkUNon4/gwJlf18rKE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ciI7k1Ia; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701766158; a=rsa-sha256; cv=none; b=YXBogOjOZay70W2MZV1EW+oi4XudJv3bUagIuqMblfN7SHj5UUac5QDxceIbVnhqoYrV6k 3j+svreF5p8S9Ku/hOTRt6DzS4RqRr87AIroVuoX3HrxBcbg+4qAWn1mPh85cG8jWDqykN AVjV7O18aiDJo8SDQVGn7LCFeJkIT44= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 017201FB7F; Tue, 5 Dec 2023 08:49:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1701766156; 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=9sZvp0Yv4XmHqd7T+QuGS//57nbANCXbTnNouufMNFk=; b=ciI7k1IaIxcDi62KcI3Gsv2F1xT1eKpt97GS8d4XRiu7YtWb1e3U4mfyNa69uziX74oaD3 AkEYTconOeevuUuWOWmKuu0GEe/WCC842HyA7hwvr6b6r6TgB1P43yIOrPaCCaJEIzQLY0 bPaPsC9UiKCViHoFHkmVZNwhk/b269I= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id ED6F9136CF; Tue, 5 Dec 2023 08:49:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id g+TzOQvkbmUJQgAAD6G6ig (envelope-from ); Tue, 05 Dec 2023 08:49:15 +0000 Date: Tue, 5 Dec 2023 09:49:15 +0100 From: Michal Hocko To: Kent Overstreet , Andrew Morton Cc: Roman Gushchin , Qi Zheng , Muchun Song , Linux-MM , "linux-kernel@vger.kernel.org Dave Chinner" Subject: Re: [PATCH 2/7] mm: shrinker: Add a .to_text() method for shrinkers Message-ID: References: <20231129231147.7msiocerq7phxnyu@moria.home.lan> <20231201014745.b2ud4w3ymztdtctu@moria.home.lan> <20231201212506.skgzaoafi5zgi3pi@moria.home.lan> <20231204181553.tyxeq7zy54cuc3o7@moria.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231204181553.tyxeq7zy54cuc3o7@moria.home.lan> X-Rspamd-Queue-Id: DCAE9140008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: pxfqa17wgpiixrb53ck3bhk6u9acbybc X-HE-Tag: 1701766157-166519 X-HE-Meta: U2FsdGVkX1//Xg2wdkhA8km3Q2toYFWu8yBSlHfvEc59k10MY+bDlI0Yy/iNsCiPciVuhfLJO7pwEunsgs4Pw0422vyJ39QnOkh0RRP8ZTBJjSwZwK3QTzhi9QJQNGLinsN1+4qJVxPg8IJpu8grV6XeHNycwX1S5GPAQLqGsMSKE1FxJKb/CwFQHs4efOMPZmrkRZ8tosE9lRIhdXilTU+mcs4y83GG5W6q2Z9cvp0KsQkVPErIezkqNAzA2bbXKAA7wvqk1bh1ejPJNM/w4wDoBe4uckQIynvaeLn1RqlCbc4xfocsJD35d1wFWf/kyIzKG8cY3Ca97tNPPTa0tGPMXBnNGrgw3fJlyUZXDGsamdFCBacjULJ6OnKqoN8AOHsrxv7WKSQ0RjehkqA3ZIlMus+KeZxks2RiLGdIauK5lpqFNkLyDxWhYXakd9HIP38cCP4q/zY2zeI3fsb0rl87nE9PJoXka/39aznC+cPanCTC28BLxuZ36lkGMJn+mpzXEE3CGvMsa+UP7zi93jiUWCtwd79a8gNv/wH0Kd+XBq2wb1pRsusUevWow0YEodX8LwOM78jnNBIJtSRhTT5/ispXo7nRV6EvXLZ9KzP4Qs08faMK7dcZNYnoo7H4A+yC5L7akAUTTIt4GKOtOYuw+4AjKqEPFZJ5dNmK3AcTMJ11gSgkgoneR/hcf+rN9Fx4nqpwSH75fXPvaKaTHLxLSz2Cn6afd+cRqELVvuJTJC6PBwctRjh6b/6scjW/IwZgmf2hptDtmeGJfq6m+6FE0oxMEGQ2yWrEyOVhateNUSvNcKB6zPNRJoOGUbK2Qm1hDxgZglTCsOnYNYG5rd4H16S5Zn3MmWyWh1YEa7eltRSqyZVZ0WLy4xylC9YIzW7ZAdyTl8vKnOYIcSJWZ4uSVVgfqTEPD5+GwFF/o4eMQT7nzMKq0gNqzOD2FA6hYIWRgw/R5jO3TcmXKTL v7/24bRi XvdDYHrE8slGFuFOlCUmwtSveecM+/9l9YYVx0NRfjWY59W0YEnx2Xb7xzapguyYXFhn65TfxaR5qyEH15BGBj2hG7Bgd9knVe423Salwjv3tkDzRErYkVvUvmt/oWRDd+5cgfCM0ne3i6o03c7ZHMAkAOhcY9p7VxUbJQpGuAHb+fAX7rBcLIGPV1PqRl/gfEqrIhCh8s0fCWpobf5wGCNIIZp+77f4YqSswv3Iu6fCQEUiJz47GBHA7ELGObrxK+mkU4At0jlQ7/wg8uT3dsuxodzVzA+qxZ/+9zCP/TBjbTgNNmG6lCMnGNw== 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 Mon 04-12-23 13:15:53, Kent Overstreet wrote: > On Mon, Dec 04, 2023 at 11:33:12AM +0100, Michal Hocko wrote: > > On Fri 01-12-23 16:25:06, Kent Overstreet wrote: > > > 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"? > > > > Yes, I still maintain my opinion on that approach. I have never > > questioned usefulness of the information. > > > > > 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. > > > > Can we do better and make that a shrinker decision rather than an > > arbitrary top N selection? The thing is that shrinkers might even not > > matter in many cases so their output would be just a balast. The number > > of objects is not universaly great choice. As Dave mentioned metdata > > might be pinning other objects. > > > > That being said, if you want to give more debugability power to > > shrinkers then it makes more sense to allow them to opt-in for the oom > > report rather than control which of them to involve from the oom > > reporting code which doesn't have enough context on its own. > > If you've got an idea for a refinement, please submit your own patch and > I'll look at incorporating it into the series. OK, noted. Let me just remind you that /me as a reviewer have pointed out several shortcomings of your proposed solution. From my POV this is not something we should merge in its current form. I am not going to comment further in this email thread as it seems you are not interested in the review feedback and I have better things to do than talking to /dev/null. This is not the first time you act like that and I really do recommend you to think about your attitude and communication style. Good luck! -- Michal Hocko SUSE Labs