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 B8A13C77B7A for ; Wed, 7 Jun 2023 02:51:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BE016B0072; Tue, 6 Jun 2023 22:51:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36DF68E0003; Tue, 6 Jun 2023 22:51:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25DDC8E0002; Tue, 6 Jun 2023 22:51:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 16C126B0072 for ; Tue, 6 Jun 2023 22:51:48 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D832EA0800 for ; Wed, 7 Jun 2023 02:51:47 +0000 (UTC) X-FDA: 80874426654.27.2C90C25 Received: from out-62.mta1.migadu.com (out-62.mta1.migadu.com [95.215.58.62]) by imf19.hostedemail.com (Postfix) with ESMTP id D91171A0002 for ; Wed, 7 Jun 2023 02:51:45 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FdUailL3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf19.hostedemail.com: domain of qi.zheng@linux.dev designates 95.215.58.62 as permitted sender) smtp.mailfrom=qi.zheng@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686106306; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=c03LqnPvSpFUegRcW9e1g0apz1BXSwwD0DXfsq/bGJ0=; b=ACWlYsUQd5v72CltBvP/ytymYawaD3zbSqQ/yQEuZWVeY2jm/Gk6SEtG7z4JinPsqKgpkf UM/5I1ukBcbKSVYFtU51sK4mcZqmDabfnXtTExf2BZOz28aoeelMrfSFvho5O5xz2dggOc vL8BEMJk4iiGm1yMJYVTGCATdEry0uc= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=FdUailL3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf19.hostedemail.com: domain of qi.zheng@linux.dev designates 95.215.58.62 as permitted sender) smtp.mailfrom=qi.zheng@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686106306; a=rsa-sha256; cv=none; b=buv7HeW96KYnuch0QVa+8dSop8j/7Iyjf8RO27bBzNhMlJxP1qyXVVJr4OrJ2eU1SK50tW wbes6Xe6AB3YPdYu2eNYer0ill0szUjzrC3gDVarD+82yBy9trdWOuoi6pfePL5RS90BLH 4yF1qr/DLmv1RjSw5PUetI6e/yRQkKs= Message-ID: <4176ef18-0125-dee8-f78a-837cb7a5c639@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1686106303; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=c03LqnPvSpFUegRcW9e1g0apz1BXSwwD0DXfsq/bGJ0=; b=FdUailL3WmNCtharci/DkkvAqyb8ew/poMMvuuMcNtImmZNAvkAMqM4ZKG8RPbZJ/+x7re R42sgBM53ZiTB0JgaH3YgE762t9Pt8YLVn6ljcYFmsyR+cPrQ04xDXSF30AyERnpgQgDce meBiZ8Jq7Ora+NndQDhxtKZMnNxEvRc= Date: Wed, 7 Jun 2023 10:51:35 +0800 MIME-Version: 1.0 Subject: Re: [PATCH v2 0/3] mm: Make unregistration of super_block shrinker more faster Content-Language: en-US To: Dave Chinner , Kirill Tkhai Cc: 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 References: <168599103578.70911.9402374667983518835.stgit@pro.pro> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: D91171A0002 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: xkyzyyamoi7ii6xaubztz89gjq86rjag X-HE-Tag: 1686106305-557991 X-HE-Meta: U2FsdGVkX1/Cfo1ftfnNmVPdUjVpbhWX1EID3VTnoWOdB/85eiXNcvGNgnh5V1MvlcAT4flxa7FvzXgnDkQ+w4bGz0uo7Kb01WpzJKxZfrN2XzEKe/yobzi4XXodc8/JsIAS7J0MitLNm5O0DFuG7Hq1DJ36UBCjQMRsdcSmcuGxBBvXJoan3zRHoIcJkiET8qMxJKqQTHbzpc3/qe2Cyx4mzuKf5gUf6vOouXkZ+XtvSewHD8Eft9wM/Suf7myU6VhI8L0XqyVLSDDvEW8AtQ9laqU/f6/KFXG6rRmGWQzMw0eKrIIk98sC+xdahLCUWCd0uZs1DyEl1Xt7T+F6IkBq6MHj495ln7BOQMvP/rqLhqb83ge+Tg62uspRHz6HjDEPmtkgQzWrwpQa1BKb3WIME4l+4l4cxAx0HD1bBVpb855T3hGH7j1rmMo8Y4CCjpNdHB/KKM5+6JNcoqccUaYkH+5Igjc6M0sMscGP5X7kYpu6tVdGncsWk2QX0vAEkmxROrU83l50A9WYH3k6tsPhOFeA/IKo1P2HiHZ947DQDtpMos1K6ncuWThhuKdC2Z7PlyxjMDGAau5SFR+2oENrVy3SCvvynW0w5xnsyOvSNSaffbGza/dxODFOuT/yM4aaxBzero1ABooY1B5d0Md1PvJBnsCYqIYKkYwD9MyOuqqX7mFTu86+91EBLcu3gozRoN/bUadi3APtfRqDJ8ATwscyA2GddM4atNEVC9TbgTs/Mb9i/PowKNJb3WGx+wuPZdm9D4gX9bBmcrPl+uTDVuCEIak/naSvmOIC8ikbBq3Wo5wd+9I0F+KjPRbyYqexLqJ0Dls8cv1Ix08umPXTMV6/GdD1yvmsjNf8rTbX6NWJ/yIaQqi1DzV4EBKMsI+qwNGBUx8BLXTExSHR2VCNsr4cGNbHn+1WFjt00aH4CBTMvy2RBlFDZUVMGoXpooI0RXBz8Ak8G1g6IwH ygLpGSgM VfQ9sPjUQsoXGTxVwZXj3kR4uHrEJHHqRNpTmg0drkXVQ7ZPB3vOAqVoDzeF54Wkom2LfVLJyudHY1kXCOIpQacxPhfk1iEwM5Rqaw2ABpDzLUwJv8hwLNdAPOboNqNBeWrv/pU8YBCtQKtZJ2jTW+dx7x+NLDX5ZzKue5leqNomlTP2ta+Boplgh/DNbydUGuuFmx7yTZyRX0yC/0n1N92Q6IC/vSKO5Oeze 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: On 2023/6/7 06:02, Dave Chinner wrote: > On Wed, Jun 07, 2023 at 12:06:03AM +0300, Kirill Tkhai wrote: >> On 06.06.2023 01:32, Dave Chinner wrote: >>> On Mon, Jun 05, 2023 at 10:02:46PM +0300, Kirill Tkhai wrote: >>>> This patch set introduces a new scheme of shrinker unregistration. It allows to split >>>> the unregistration in two parts: fast and slow. This allows to hide slow part from >>>> a user, so user-visible unregistration becomes fast. >>>> >>>> This fixes the -88.8% regression of stress-ng.ramfs.ops_per_sec noticed >>>> by kernel test robot: >>>> >>>> https://lore.kernel.org/lkml/202305230837.db2c233f-yujie.liu@intel.com/ >>>> >>>> --- >>>> >>>> Kirill Tkhai (2): >>>> mm: Split unregister_shrinker() in fast and slow part >>>> fs: Use delayed shrinker unregistration >>> >>> Did you test any filesystem other than ramfs? >>> >>> Filesystems more complex than ramfs have internal shrinkers, and so >>> they will still be running the slow synchronize_srcu() - potentially >>> multiple times! - in every unmount. Both XFS and ext4 have 3 >>> internal shrinker instances per mount, so they will still call >>> synchronize_srcu() at least 3 times per unmount after this change. >>> >>> What about any other subsystem that runs a shrinker - do they have >>> context depedent shrinker instances that get frequently created and >>> destroyed? They'll need the same treatment. >> >> Of course, all of shrinkers should be fixed. This patch set just aims to describe >> the idea more wider, because I'm not sure most people read replys to kernel robot reports. Thank you, Kirill. >> >> This is my suggestion of way to go. Probably, Qi is right person to ask whether >> we're going to extend this and to maintain f95bdb700bc6 in tree. >> >> There is not much time. Unfortunately, kernel test robot reported this significantly late. > > And that's why it should be reverted rather than trying to rush to > try to fix it. > > I'm kind of tired of finding out about mm reclaim regressions only > when I see patches making naive and/or broken changes to subsystem > shrinker implementations without any real clue about what they are > doing. If people/subsystems who maintain shrinker implementations > were cc'd on the changes to the shrinker implementation, this would > have all been resolved before merging occurred.... > > Lockless shrinker lists need a heap of supporting changes to be done > first so that they aren't reliant on synchronise_srcu() *at all*. If > the code was properly designed in the first place (i.e. dynamic > shrinker structures freed via call_rcu()), we wouldn't be in rushing > to fix weird regressions right now. > > Can we please revert this and start again with a properly throught > out and reveiwed design? I have no idea on whether to revert this, I follow the final decision of the community. 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). 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. And hi Dave, I know you're mad that I didn't cc you in the original patch. 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. Qi. > > -Dave.