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 41B3DC61DA4 for ; Thu, 9 Mar 2023 19:34:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D6AD280001; Thu, 9 Mar 2023 14:34:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 986AB6B0074; Thu, 9 Mar 2023 14:34:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 84E39280001; Thu, 9 Mar 2023 14:34:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 765026B0072 for ; Thu, 9 Mar 2023 14:34:27 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3FE40A11D1 for ; Thu, 9 Mar 2023 19:34:27 +0000 (UTC) X-FDA: 80550361374.12.2603F7F Received: from forward500c.mail.yandex.net (forward500c.mail.yandex.net [178.154.239.208]) by imf29.hostedemail.com (Postfix) with ESMTP id 10CE0120013 for ; Thu, 9 Mar 2023 19:34:24 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=ya.ru header.s=mail header.b=V35pElRH; spf=pass (imf29.hostedemail.com: domain of tkhai@ya.ru designates 178.154.239.208 as permitted sender) smtp.mailfrom=tkhai@ya.ru; dmarc=pass (policy=none) header.from=ya.ru ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678390465; 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=QnAXpX051nzPo+8CEjdAzCSqmApdQEykiwFVcf/r99c=; b=YmQz+xNCGasdgZZlrxORbraNE9f8Q2tVMUOsRwsG4oZxwe8XULiAvqT8iHKVphJNq1IlJm C05zWK3Al+2b1mVPl91Rj7Hun4Z2WPS4Tw2IvLMc6SmtJx7kT1UgfgunFZLcq9NZ75eEJ2 I/DCs5/13K5TXl2+HBbdIdAy/6Ndavo= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=ya.ru header.s=mail header.b=V35pElRH; spf=pass (imf29.hostedemail.com: domain of tkhai@ya.ru designates 178.154.239.208 as permitted sender) smtp.mailfrom=tkhai@ya.ru; dmarc=pass (policy=none) header.from=ya.ru ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678390465; a=rsa-sha256; cv=none; b=mCXCO4+QzCWvQDMvCxSTCKbc+w9dJodgwYZbowc49rkxYRqhZANeWmD96/Yprn1afnEje1 uyUs/6w+kh+9b+L03NDlAbW427R7GZ9MNecgMAPPMc153Egm4FasNEyLZ2M17pBWChEG9S WON7GKTD8B1cuw6w0FuLw3V35LZ3qM8= Received: from iva6-eccc17c3aa65.qloud-c.yandex.net (iva6-eccc17c3aa65.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:7598:0:640:eccc:17c3]) by forward500c.mail.yandex.net (Yandex) with ESMTP id 3B0EE5F10E; Thu, 9 Mar 2023 22:34:22 +0300 (MSK) Received: by iva6-eccc17c3aa65.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id JYjOWj5btOs1-U1Zmn3cx; Thu, 09 Mar 2023 22:34:21 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1678390461; bh=QnAXpX051nzPo+8CEjdAzCSqmApdQEykiwFVcf/r99c=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=V35pElRHX3fwN2fxLVizqwLZ0py0quD4YexSY7g6jYgHfDft5I9mvjukJ/1rU99VW YwsmHRkc6I5vWEn1set1htf0y2KctN0CdnAcr0PFDdGT/6040qY/reyWrktJGNsYXU kKxR2y36EQ47dY9zCpOUU7wB7dqJa4uDLbS1Qm7k= Message-ID: Date: Thu, 9 Mar 2023 22:34:18 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v4 7/8] mm: vmscan: remove shrinker_rwsem from synchronize_shrinkers() Content-Language: en-US To: Qi Zheng , =?UTF-8?Q?Christian_K=c3=b6nig?= , akpm@linux-foundation.org, hannes@cmpxchg.org, shakeelb@google.com, mhocko@kernel.org, roman.gushchin@linux.dev, muchun.song@linux.dev, david@redhat.com, shy828301@gmail.com, rppt@kernel.org Cc: sultan@kerneltoast.com, dave@stgolabs.net, penguin-kernel@I-love.SAKURA.ne.jp, paulmck@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230307065605.58209-1-zhengqi.arch@bytedance.com> <20230307065605.58209-8-zhengqi.arch@bytedance.com> <07078623-b7ef-ceb4-eccc-8872a4067273@bytedance.com> <85f9e200-dabe-7340-b76d-6525988054aa@bytedance.com> From: Kirill Tkhai In-Reply-To: <85f9e200-dabe-7340-b76d-6525988054aa@bytedance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 10CE0120013 X-Rspam-User: X-Stat-Signature: 1ssuwgoheci36zkrin6n4qnnd3ecgyce X-HE-Tag: 1678390464-848522 X-HE-Meta: U2FsdGVkX19+z4nHksCUygqiPnncryrO4thfEh7UsbgARbU+iIC3fKTD5bCg8yyomEC9SZnLUW4XOluPTPEk0HEwhF4RjkS80A5ZvRje5ri3EB4FvNwoZg9QC0vaymjf2t6/Ag94EQ0SEEASyCIKuNmytgaCDyu6sD65AT+O6s0MD0XA6MuTu8pIuKS0z0HKpHwTUnyfQxcA2T32Krb4dPE/+wOh0t0ibd44g8cxiYKxVZDJAuY8QnTeKHVarU4JEBWnZkIXn9iRsAQBaR1EodDyKL7uBYcERg4SfI/FNLomNns/HaApXgjo3eb7vX/jAu0BOOMFRq0Xn6l6TZK+tzNDi1wfDcQ4wjYepgr9hQRSDR6ysycn54LhHO0vKNajTC8PkSAIgr8KtJfHXNBqH73IqpWLOwE5VCXYWCXC3enuEMZF7vmOmwcIseDz+C192/IsC7dKDOsuw+3aKZGTh9OrI7aQZTJH4yRBM49mUtI6koHfqJoQqgskn6zgY7hw2svxkbKfx4NZ2OebMaexaj8v5kQc44fcuyyD3NnPu6ddYXR0ICo4DgT8a/YFWYJky5pjGJ1DN9q8u0Pla2BVON+g37LTBB6hAmQIDA/sgFhNRhzlzo9RwJo2aBgMyNVrSaEuF1KLmbhQN1o4ZTXVcYYe2ko5KLE8BwyizM6NsrqAic4D1Hs2M/MCzIClbH6Tc5f0b/JFCqP35nZL3kza6j/lNxgQUbZrdwuKUYAwwpg6KkXkM1QtjgO7BMh4ja5aD9bJPfI2He8AXa6VZpiPUwDEkSy4b/fm/Wdf2odq5dpAfpQzN65UU19pHF1rysrDutsAYQERz2GuPOHpGL1aF/gt64v9HAxJyt1BiLFgoujjV7t1CL8uwqtJlxt5f+PSPoUnMSULO4z8ewP2+nZoiJffPa5V/m+G/5SQ8drTtxnwYs3cMScvDYOgdaq6dYxuZdYGOoeikSfg89yo6nX ZVELnniL YCR+wKy2glc11jDqfVfwhy/TxYZ8DlreAQWk4n6yuGVsYtz17Y3BFOVmqP1IoOszAG34V7GNmGYct24y4ljZGZedyr+uQKudyBOKVW+U/bplY3zXbMM71570+JbrqHi7RhPXHoUZbvUSDd4Lasz87is7M6rTr8c9zoxvCueHIosp+2H1Zr2wnJKq6GHfJximT1EEcvYIlXVGurOJloxQaSIrZkUpeIhQct4M/Oj14wDfnUkV4KK9lFjWj+WSOFc1yxBmUBk9BBXMxUqBXiO1eiK3ZNO9geSoWCqMLB2hXjR4m4iCIp/APgs7UTaRJtHKPSLc2wssyZNMeKhHuuNsIVTp0s5BlN4N4kmVMZOiOwD42bQzKEiPN/0k7++tKB5nyDjJkf8iiOFCB+tQ= 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 09.03.2023 11:32, Qi Zheng wrote: > Hi Christian, > > On 2023/3/9 16:11, Christian König wrote: >> Am 09.03.23 um 08:06 schrieb Qi Zheng: >>> Hi Kirill, >>> >>> On 2023/3/9 06:39, Kirill Tkhai wrote: >>>> On 07.03.2023 09:56, Qi Zheng wrote: >>>>> Now there are no readers of shrinker_rwsem, so >>>>> synchronize_shrinkers() does not need to hold the >>>>> writer of shrinker_rwsem to wait for all running >>>>> shinkers to complete, synchronize_srcu() is enough. >>>>> >>>>> Signed-off-by: Qi Zheng >>>>> --- >>>>>   mm/vmscan.c | 8 ++------ >>>>>   1 file changed, 2 insertions(+), 6 deletions(-) >>>>> >>>>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>>>> index 7aaf6f94ac1b..ac7ab4aa344f 100644 >>>>> --- a/mm/vmscan.c >>>>> +++ b/mm/vmscan.c >>>>> @@ -796,15 +796,11 @@ EXPORT_SYMBOL(unregister_shrinker); >>>>>   /** >>>>>    * synchronize_shrinkers - Wait for all running shrinkers to complete. >>>>>    * >>>>> - * This is equivalent to calling unregister_shrink() and register_shrinker(), >>>>> - * but atomically and with less overhead. This is useful to guarantee that all >>>>> - * shrinker invocations have seen an update, before freeing memory, similar to >>>>> - * rcu. >>>>> + * This is useful to guarantee that all shrinker invocations have seen an >>>>> + * update, before freeing memory. >>>>>    */ >>>>>   void synchronize_shrinkers(void) >>>>>   { >>>>> -    down_write(&shrinker_rwsem); >>>>> -    up_write(&shrinker_rwsem); >>>>>       atomic_inc(&shrinker_srcu_generation); >>>>>       synchronize_srcu(&shrinker_srcu); >>>>>   } >>>> >>>> Just curious, callers of synchronize_shrinkers() don't want to have parallel register_shrinker() and unregister_shrink() are completed? >>>> Here we only should wait for parallel shrink_slab(), correct? >>> >>> I think yes. >>> >>> The synchronize_shrinkers() is currently only used by TTM pool. >>> >>> In TTM pool, a shrinker named "drm-ttm_pool" is registered, and >>> the scan_objects callback will pick an entry from its own shrinker_list: >>> >>> ttm_pool_shrink >>> --> spin_lock(&shrinker_lock); >>>     pt = list_first_entry(&shrinker_list, typeof(*pt), shrinker_list); >>>     list_move_tail(&pt->shrinker_list, &shrinker_list); >>>     spin_unlock(&shrinker_lock); >>> >>> These entries have been removed from shrinker_list before calling >>> synchronize_shrinkers(): >>> >>> ttm_pool_fini >>> --> ttm_pool_type_fini >>>     --> spin_lock(&shrinker_lock); >>>     list_del(&pt->shrinker_list); >>>     spin_unlock(&shrinker_lock); >>>     synchronize_shrinkers >>> >>> So IIUC, we only need to wait for the parallel shrink_slab() here. Like >>> its comment says: >>> >>> /* We removed the pool types from the LRU, but we need to also make sure >>>  * that no shrinker is concurrently freeing pages from the pool. >>>  */ >> >> Yes your analyses is completely correct. >> >> I just didn't wanted to add another SRCU into the critical code paths of the TTM pool just for device hot plug when I have that functionality already. >> >> We just make sure that no shrinker is running in parallel with destruction of the pool. Registering and unregistering is harmless. > > That's great, thanks for confirming. > > Thanks, > Qi Christian and Qi, thanks for the explanation. >> >> Regards, >> Christian. >> >>> >>> + CC: Christian König :) >>> >>> Thanks, >>> Qi >> >>