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 DB2FDEB64DD for ; Thu, 27 Jul 2023 23:48:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1EC4A6B0072; Thu, 27 Jul 2023 19:48:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 19D1C6B0074; Thu, 27 Jul 2023 19:48:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03CF76B0075; Thu, 27 Jul 2023 19:48:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E60296B0072 for ; Thu, 27 Jul 2023 19:48:47 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B4A6A1C9319 for ; Thu, 27 Jul 2023 23:48:47 +0000 (UTC) X-FDA: 81059034294.30.BDE96B5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id DF592C0005 for ; Thu, 27 Jul 2023 23:48:45 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ak6ozI5M; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of dlemoal@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dlemoal@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690501726; 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=GhQYpQtzB93TK2lOPrHFGZqAvfZLTmLHDaXv2Rau1bA=; b=3s5RFSYd8zevVojnFeOHPl8VEYjiaiOzQZtG770htWQmMUU38cikVQyV/cNZNosRFD6Aql 4AUlMnqgdLW25FnyFmtKpanZDz4WxfAL6/wo7GScgAkFgobecHRvBYytyX4jvQ/oBewqsT HcnrqX8Pm/wOvHVCQUuboHuCzlzO8bY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ak6ozI5M; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of dlemoal@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dlemoal@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690501726; a=rsa-sha256; cv=none; b=UHnoo8PiTjLRPwUakLNr/bz1zS4X1mqkYtOAdlZZlnY4JMhlNjBdS/cBV36AzZl9KsCCDJ CuUrhvo3YEe8DL47sR1VYrHUakefTuT5X6IZ6Q0ift8g5Jw3AD3IC6NuYI8NqPtCfS2TfS BPZH9Ud5W/NdXHSVsMhHsHVoxPt1fcw= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CA7BB61F8A; Thu, 27 Jul 2023 23:48:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E5FDC433C7; Thu, 27 Jul 2023 23:48:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690501724; bh=Ttxo2VAoV3s10tVDpG1rs4f+uNBtPiAAdsRn7qEPqAI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Ak6ozI5MGJ+V/aaPZbipUbe6ZARep0hinqcaIFmiUbGlXqA4l6qqKubv3sXd24Wis E3nRqNpMPjywrGRezhx8kIl9BfOcFGOjuYtEl0wjzGKmd2W/r6L34Y8Q/Asia9+Ai+ N65piXMA54Y1i5SwziMjZGbgl+PlpLxLOgApRck3LvpJfpGiaZrCds1yq/RX5+TIOO TcyhaMq04sGg4mmvI/xNg53Zl5ogRkSJoPUjgXBUN2wkW+R/Z24fG4Bcn7szmrfhkb 1Y0rUs2KyI/CXZncywoQIP9j5+uNlee3CVuHYo0iSwOTdXpuIWfOUm7reRjWTqpcd1 EASuIvTp5UKtQ== Message-ID: <217f3a7e-7681-0da6-aaa7-252a1451f7ba@kernel.org> Date: Fri, 28 Jul 2023 08:48:37 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v3 28/49] dm zoned: dynamically allocate the dm-zoned-meta shrinker To: Dave Chinner Cc: Qi Zheng , linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org, linux-erofs@lists.ozlabs.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, linux-nfs@vger.kernel.org, linux-mtd@lists.infradead.org, rcu@vger.kernel.org, netdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, linux-bcache@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, Muchun Song , akpm@linux-foundation.org, tkhai@ya.ru, vbabka@suse.cz, roman.gushchin@linux.dev, djwong@kernel.org, brauner@kernel.org, paulmck@kernel.org, tytso@mit.edu, steven.price@arm.com, cel@kernel.org, senozhatsky@chromium.org, yujie.liu@intel.com, gregkh@linuxfoundation.org, muchun.song@linux.dev References: <20230727080502.77895-1-zhengqi.arch@bytedance.com> <20230727080502.77895-29-zhengqi.arch@bytedance.com> <56ee1d92-28ee-81cb-9c41-6ca7ea6556b0@bytedance.com> Content-Language: en-US From: Damien Le Moal Organization: Western Digital Research In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: DF592C0005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ot8ebj9kzey8hkb15zg44io6qdist3r3 X-HE-Tag: 1690501725-877267 X-HE-Meta: U2FsdGVkX1+ex/LZ3Id9PYYSLhTU5uxpZ6eFCY8oUdxWIN5lGQ4JLFbUVbCQVinRsi7TwSPVBnyT0w99f3VCtnrq9dVptAJvgRLBebDq5ZrMk6q84y8x7tVwk7Dvr2XsmUfIzMwT83rinj3JKkLYm/vCjnlmLdGviqRzS/MYotDF9qGTpY1MOnaSmlYvMD6OG4TKi6+ShBQKVaN4GuL4oVWCh0DZ10NWi40J+lIQfM9X8j0CKwyT9x0Hy8wJdsJ9hpEBGYNLHcJcJj0acgO2XTfaql9+RqkpLBuWdhiBpW+ccTEKCEFrsDE8055cj+sh6s+NDPczh4Mpbc1na9BoYgYmTDrjfqBe/rquGuQmYa/PwdrwXLComf8fDV5gzMdQr0RNtzIJQ16f9BHenWY0ZV1WbraL8o16iQhwatDhi+0F5j4SDp+4jNRXEKaCn+1FvdJU8jd49ELQVE0EFp09DWVmcqF0RKFGsK4kiwQvaMwXVFHClAdcyCC+Nb8e5tZu9rleTqCG6xdx44IlgIkebjGGP0F1TwWGOKDigglhI0ogRqgfGskOjuwKNlz6HNbi8FkLH3wKl1SwGMHCgxW9qvSIHnpAIOUCokj0JyF+/Ctxo12yx0XHw56JlftrjizbOgklJjHOcB0X3VpVTEc19I8xCS8PzYzx1NjAioJuKceRiUNauEhwbzP81Rd6Ck8oEBu17XqR1OCDJ/I+vlqYNOkRB9wYRnHIn/S7NrI5714QDn+lBdnNZT/izyY6JBQuzO6ewMKPjxJbH84qozYp8Ad7Xp5+5rLDxttE7FP14ULqPUIeJwQquvwJ7atZyWjOXRRk6n29YJznyO6OSkXqX0E3EsR+CxBNQo5KRFLdeDf31xkmHX6V0xQPI0WJztXu7/r2/wRA6wahqUIYp+/mdXRkcuZmya7GFsYQbady3SkZDyMFwa2C/yd4owHlRzdis/teScVsSfjyJ35Bllw mFoaJLSb ZomPrtCRsq5s1ybzVLjNO3/utyTyJ3rzQk5QUO+T2Qf4apumwHqTlZ0sI/Bbbym7Bc1O9L7ds0h/tVvYD+LG2DxSRec6iQc+rSALKP0RoWNXqfaUivl5LAmqNkAq9Z4YyBtbHkLYLzm4Uy96WgkDuN7MUraUZukjx9V1RlxgOlK5+az8xPyKXKldRKXsoymv3GCMYmHTx+wg1M6s995S/JY2QLn/lrEGfr/w6JmhLFo1hVHVoeT/kuCAw30oeUkV8sVdObGSCB2D/T3L/rhS2qk6AsHlb50tcP+WWqUbImrq7a9WzY3yeeJJvPIPxdlSKjJes9kHzVjzQ4S8= 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 7/28/23 07:59, Dave Chinner wrote: > On Thu, Jul 27, 2023 at 07:20:46PM +0900, Damien Le Moal wrote: >> On 7/27/23 17:55, Qi Zheng wrote: >>>>>           goto err; >>>>>       } >>>>>   +    zmd->mblk_shrinker->count_objects = dmz_mblock_shrinker_count; >>>>> +    zmd->mblk_shrinker->scan_objects = dmz_mblock_shrinker_scan; >>>>> +    zmd->mblk_shrinker->seeks = DEFAULT_SEEKS; >>>>> +    zmd->mblk_shrinker->private_data = zmd; >>>>> + >>>>> +    shrinker_register(zmd->mblk_shrinker); >>>> >>>> I fail to see how this new shrinker API is better... Why isn't there a >>>> shrinker_alloc_and_register() function ? That would avoid adding all this code >>>> all over the place as the new API call would be very similar to the current >>>> shrinker_register() call with static allocation. >>> >>> In some registration scenarios, memory needs to be allocated in advance. >>> So we continue to use the previous prealloc/register_prepared() >>> algorithm. The shrinker_alloc_and_register() is just a helper function >>> that combines the two, and this increases the number of APIs that >>> shrinker exposes to the outside, so I choose not to add this helper. >> >> And that results in more code in many places instead of less code + a simple >> inline helper in the shrinker header file... > > It's not just a "simple helper" - it's a function that has to take 6 > or 7 parameters with a return value that must be checked and > handled. > > This was done in the first versions of the patch set - the amount of > code in each caller does not go down and, IMO, was much harder to > read and determine "this is obviously correct" that what we have > now. > >> So not adding that super simple >> helper is not exactly the best choice in my opinion. > > Each to their own - I much prefer the existing style/API over having > to go look up a helper function every time I want to check some > random shrinker has been set up correctly.... OK. All fair points. -- Damien Le Moal Western Digital Research