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 03573C7EE43 for ; Thu, 8 Jun 2023 21:58:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E96A6B0072; Thu, 8 Jun 2023 17:58:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 571998E0001; Thu, 8 Jun 2023 17:58:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 438756B0075; Thu, 8 Jun 2023 17:58:53 -0400 (EDT) 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 316736B0072 for ; Thu, 8 Jun 2023 17:58:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F345E12053B for ; Thu, 8 Jun 2023 21:58:52 +0000 (UTC) X-FDA: 80880946104.07.0097541 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf10.hostedemail.com (Postfix) with ESMTP id F2E3EC002C for ; Thu, 8 Jun 2023 21:58:50 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=cZPc7zSy; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf10.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686261531; 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=2/EUtx4ycp4mR6nPhVhDlxvnjzE+zvrfRKVHftXyUsQ=; b=5M59lpcjbn9MawCZ/82EGqfuhP4IETACs+h+FXWJhnzJPzcbnU0Tiro0Wri+A5uPRQYj9U Ui1LrQEVfPd5o2oF/tZRAJtLQ86B9N3epIBhfQS2FCr/k/r1RwRHwKKQE1sBwRPoyQjt85 a5oqSwYVj6u7Z3/RXLpJI8pWgKNezuw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=cZPc7zSy; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf10.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686261531; a=rsa-sha256; cv=none; b=m069Vmy/I6k2xBrIUeJtZYgUBa81qZBQh07kszfaOrA/KNV2PwM6xYwJwZK5wk2W91/BPo qhgViwymBEtMHUqS9OLUWVMpQhLyVM/ZFPYPOvPQfGRiUfWnmczAD2i6ddr1O3JDUNHj0H r/ZK8X7Xrba+NiKmWcsJnzPy8aAxOo8= Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1b038064d97so1329765ad.0 for ; Thu, 08 Jun 2023 14:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1686261530; x=1688853530; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2/EUtx4ycp4mR6nPhVhDlxvnjzE+zvrfRKVHftXyUsQ=; b=cZPc7zSylxAT6FpIE4tHSHILj+81IHIUImhSd8x1ZEh9BfDo9ClhPAllJEIFmD3i9Z uNVf/KVDMMqXPqGfFx5jiiKabbZUnA2s0R0II2nJq5M/glD3LrAzYS+0OgWfXreFGBkC TG1jMPCIriroCZOIAcZFvO8mM0PqHw1mhENYRK2DbP44uA/FljkfwDXrum1S1yKOCh3H IJK3euKv7R22rYss/6OuXYIaivjw9MeRNiXoHKwPIYz14nw39r8LXPdbz8JzTyocMh76 McmR72bUJqRzn2Vn2N13e6tQYVYxF5qxOH2zfFW+8TZgheIgz7osiJkYCRyzn3s9PHVq cJpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686261530; x=1688853530; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2/EUtx4ycp4mR6nPhVhDlxvnjzE+zvrfRKVHftXyUsQ=; b=Eu0S65EDobUFaGD0sftcdDJZLmS6y8MajC9LtuD2Fihg+HAeQTQCGql/GxXdQU54GE Js2XQsLz+1zUQcL1BkL1R2O4r732054H8zzxI8BfYAj8xnMIzOLvEprqSxFkA3BI9o3i Hu+OLrbiLuRclG7TGVoBOhDiIIDuXQOyk5zFrjZigjEvw8N18TQhzMtiT4bgLZBG1BOH TBCJsb5K5UiJBzWQtMP2+MckCSv4Ufes4aAKfJlSiBrDHdadS7Cm1Z4Z4n4OcRm1jU2y HJ2VF3jATwATi7RZlQNUNVx0B6E3YXayyIDzMqb395PujbDshFBwaklLUq0bhd89Kvf+ 2/vQ== X-Gm-Message-State: AC+VfDzVw62UdmPTXJknneZu6HCPrlRkaU6bJS2aMp2uCiVKcyNQBbSX +7aRvC/ZIFidSaGG5G6QUe+aironJc9bgAeLQcc= X-Google-Smtp-Source: ACHHUZ4HayHnFpb+wxhgpMUZycBd+h1pMgzOPGOqp2bjrxn/nE2uyMC88SzBjmeIuSiMFNqtn8mg4g== X-Received: by 2002:a17:902:c952:b0:1b0:3d03:4179 with SMTP id i18-20020a170902c95200b001b03d034179mr4073208pla.6.1686261529696; Thu, 08 Jun 2023 14:58:49 -0700 (PDT) Received: from dread.disaster.area (pa49-179-79-151.pa.nsw.optusnet.com.au. [49.179.79.151]) by smtp.gmail.com with ESMTPSA id 4-20020a170902c14400b001b03d543549sm1892229plj.72.2023.06.08.14.58.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jun 2023 14:58:49 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1q7NeY-009Rru-0V; Fri, 09 Jun 2023 07:58:46 +1000 Date: Fri, 9 Jun 2023 07:58:46 +1000 From: Dave Chinner To: Qi Zheng Cc: Kirill Tkhai , akpm@linux-foundation.org, roman.gushchin@linux.dev, vbabka@suse.cz, viro@zeniv.linux.org.uk, brauner@kernel.org, djwong@kernel.org, hughd@google.com, paulmck@kernel.org, muchun.song@linux.dev, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: Re: [PATCH v2 0/3] mm: Make unregistration of super_block shrinker more faster Message-ID: References: <168599103578.70911.9402374667983518835.stgit@pro.pro> <4176ef18-0125-dee8-f78a-837cb7a5c639@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4176ef18-0125-dee8-f78a-837cb7a5c639@linux.dev> X-Rspamd-Queue-Id: F2E3EC002C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: y58xaewu4msxt3naxhk179jetumbc863 X-HE-Tag: 1686261530-841080 X-HE-Meta: U2FsdGVkX1/xk6UNVVtX/RsxBtwtBuKDHEUvrnfYF6sxmBGobHcsT6RzLgJ/WdQANrniFDrzJu00S699HlOQh4YN7eUVezWj5MOtVyNgiyObEt/WgeL5CYDRZmiU22JhKdebmo+xezchQDJze+JDJ8+1gVynq1z2EOjcvfaGuaxug1pv0Uariuf8e/sUgiPfXlbb01vMn0mA6EX7z85aAKB9wYN07Q6MbFx/4zWj94thUtH6AUaCrJQUJTP1s8YKMh946X0dSNKtHcm7W7rA16s7pUAGtKz7dTvRcJU2Ngq1I7oqSUcXkFmprtxNiBl++Rtqn2LAtyAl4eRFztcO3LAefEtfaf9JnxcooP+hfm0pQl9LxKyHd5+P99kQKS7mkiRVFPNS6HTphkHQVrw/81aCx1JgtTP0CZ97+tU7gl4qKSB0OIr5FcJkInRPL2EH5UAPlAcgts9nxxCs+yOuQRo1OXOAj4veDAKDfsUTrjSsVBQ/PPxnGpYL4Awl0nhx0O7jh2e0hsh5PrOm2ch9nnfvgp9uS6EMFlrPVXNL4/i6TM9d1ieRw7BMFza47Li99sX5L4cxlHFAFKQSbKiT2+Z1JxxlZqXmjYCzye/3mgEXEUUWpB3tRKq4C0EIFzmyeaHPfNgIl9M413XeAU43WLkGWfVrsPAIg58JVw70i0lDmH03k08EYIZiqV7iKcMTxV78ExNoCIUHhOsgnSAb4Qt6vkRCXcMYHGhJOnA6IExmYStpJR0ffkfQ5pTQxz/K+U70XAakRiDBF3adtwpM1Ay2ViO2fUq5RW0ZHhri9tgc/lLoUISfAbYSWCBzJDdPVlUNQLQhd0Yv7WQNKgFi1FjWjjhtx4o2kyTKPO74B3AXC1xckUMGdjcyCF1VX7Pxif67qUFmIxHrEfWiEtL5Ht6gXqTMZM18vh1Dz7GANcpjkGH4lwN/aewb8yoaloN/llGBRDlicaIRNgkBOm4 Ksq5HXHz yKDbiDttTsK+HyQzNIUyLmXvVeLV84V+ygmf4TacoBsy5QCUL7YL30CboP0OLemZSL3aMUC2SZYueIwgqCn2ofwh7xsv/fI0FidEZ8bwDUvWUvgFGcUdvvKfZgx7pH70PUlNw5+ZoKqnTojLfchoC2Wqq7KGQ5OfyLPEA009SZzp7YzJm5yjllRIzXTQZ8U4ZsTCNTJLea71nSmUwHyX6WPHJ7EFJed2gA8y5n5ftRQ9lwMccq/3dknSlGIxVeiIzGcnMWnAzoFu2isKKCGXNFoSaHDEXpanhbGY0tuq4D05V7wXF0Wu8nJMmTYTURM5zJG32BU7vZC2WzA4kY9Qs8DodugmIlLifpbDsSmaRQSrAkcfYcaZUz9ewZcwaDlEW3po4veJni1zH38DkfH1bVoLUmZSSnyOYaj0BODLUdR8HKjFYKs+ZVEJvjanJaKscSghyxddovLBiHE/4VCmj6t8CGQQDa7m5cGO8H2xov9DtapkEMrYqmrLVKnE31OXdI23MMZNFn2E4VcZKPzTVju7dNiz2W1ExLvvnI3crwvh/TofKQWhgBeVehw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000539, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 07, 2023 at 10:51:35AM +0800, Qi Zheng wrote: > From my personal point of view, I think it is worth sacrificing the > speed of unregistration alone compared to the benefits it brings > (lockless shrink, etc). Nobody is questioning whether this is a worthwhile improvement. The lockless shrinker instance iteration is definitely a good direction to move in. The problem is the -process- that has been followed has lead to a very sub-optimal result. > Of course, it would be better if there is a more perfect solution. > If you have a better idea, it might be better to post the code first for > discussion. Otherwise, I am afraid that if we just revert it, the > problem of shrinker_rwsem will continue for many years. No, a revert doesn't mean we don't want the change; a revert means the way the change was attempted has caused unexpected problems. We need to go back to the drawing board and work out a better way to do this. > And hi Dave, I know you're mad that I didn't cc you in the original > patch. No, I'm not mad at you. If I'm annoyed at anyone, it's the senior mm developers and maintainers that I'm annoyed at - not informing relevant parties about modifications to shrinker infrastructure or implementations has lead to regressions escaping out to user systems multiple times in the past. Yet here we are again.... > Sorry again. How about splitting shrinker-related codes into > the separate files? Then we can add a MAINTAINERS entry to it and add > linux-fsdevel@vger.kernel.org to this entry? So that future people > will not miss to cc fs folks. I don't think that fixes the problem, because the scope if much wider than fs-devel: look at all the different subsystems that have a shrinker. The whole kernel development process has always worked by the rule that we're changing common infrastructure, all the subsystems using that infrastructure need to be cc'd on the changes to the infrastructure they are using. Just cc'ing -fsdevel isn't enough, we've also got shrinkers in graphics driver infrastructure, *RCU*, virtio, DM, bcache and various other subsystems. And I'm betting most of them don't know that significant changes have been made to how the shrinkers work.... Cheers, Dave. -- Dave Chinner david@fromorbit.com