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 50FC9CE8E9D for ; Thu, 24 Oct 2024 18:54:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA4ED6B0088; Thu, 24 Oct 2024 14:54:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2FA66B008A; Thu, 24 Oct 2024 14:54:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACE846B008C; Thu, 24 Oct 2024 14:54:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8E78B6B0088 for ; Thu, 24 Oct 2024 14:54:11 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DF8FE8124F for ; Thu, 24 Oct 2024 18:53:54 +0000 (UTC) X-FDA: 82709395650.02.30EEB08 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf27.hostedemail.com (Postfix) with ESMTP id 3E8D840008 for ; Thu, 24 Oct 2024 18:53:49 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VogRliWa; spf=pass (imf27.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729795971; a=rsa-sha256; cv=none; b=ALDM6kfknFEWQU6nAZr418IDTsh4YovkyaDVlUz0EuMyhV1tqLVostoNOW+gAQI5FA1T2e j5jdWKtpIK4mbaAKnDRpjUyBnHQo4KIDAX7dpg0Ld6h6Yy6e8bI9sL0p8qFmIu8KbKrDn3 dnW5tlC79oMCIxa8GNvk3TjKps1+wYk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=VogRliWa; spf=pass (imf27.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729795971; 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=0KlqshmPXbxZTAr3w7RRmiAJaVrc05CpdJhCJXtLXB4=; b=c0D9oYgkmFsDpEjUjFMOPvAediaemcHOe177IgLhZJBZUi8Ch5FrpoOcl4GDDLoNmlpbRk 6N0fpzdvr+6jSdruVRmGhPVmybBvyL8Xkh+35NGR2qgG5aiK5MS7Dn+YUkB7eCgB4nf7k5 Imh9nwcZBURbgQX3vlJmT/hapzk8O/I= Date: Thu, 24 Oct 2024 18:54:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729796046; 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: in-reply-to:in-reply-to:references:references; bh=0KlqshmPXbxZTAr3w7RRmiAJaVrc05CpdJhCJXtLXB4=; b=VogRliWa+azQMsfmhGUG4zqTaQtU2omksMFKCMz5Qcg6h41JqOKX1fWACEZjhFf5SMKDHF TFdPj32qCtkRn15xJ2VGBtl/TRekR/kvyTWSMQUPzc6VWgB6yxs51ZRH4mIUGewvdT3RwO oBvC3UcklSbPtoGVhrqEVx46MN0qHBM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Shakeel Butt Cc: Michal Hocko , Andrew Morton , Johannes Weiner , Muchun Song , Hugh Dickins , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, Meta kernel team Subject: Re: [RFC PATCH 3/3] memcg-v1: remove memcg move locking code Message-ID: References: <20241024065712.1274481-1-shakeel.butt@linux.dev> <20241024065712.1274481-4-shakeel.butt@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: d5p43jqnes6s1dnayc7gmmuim4y73rea X-Rspamd-Queue-Id: 3E8D840008 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1729796029-841830 X-HE-Meta: U2FsdGVkX1/RJmmEPapfRktl9pQfLpN4GCUDl+d5QRrvaar3lcPOLRGIBijfKE9u3kDUW4v4AXix+pG6XiiipRyh0UXKPtzLb9FcUFQF3oUl7EZCSUK7sZsWhr3yHfCyHBGWXdwSqLZbSunCq+GVDAOEkj9l3fjZVhGUvGKvwk0/iFVMXSAFnQdgx9RsO5Ut4a3rqPn4CCFoy3JDAuD/lL15PULDagbleLyIEu1Kc9DS7W0zkzXiGFjwDglS5xnmBrKsFbVviNn5HL2uEZEsVuI4y403wusrjJMGBU0SccmCu/1JauWklRTO3Hz1m1IeljnyqKfdqkFAeMtD74iMi7AnJXCNs8fd/o4UBkp5srdpCZUs5Fb0ddALrP+ebSIlMqQz18YAnqgQ1536Dk2/FpyIOEZV/0jO4q0srYHcTgu4SIV/6HQJiOQnWJgF3D/ShxqLxsnel+VB/kecehUsCN0v1OaC8ERVqkKESPX0WOBKy1w/6MY58Be3cTAIftHUKzT2E3Z/HZDMUeudFd9m9b1+iqRT1Y6jnh6ql4P70HoXs+nh2ntm9i9aQq6cG7GizXYDGBTDF+SEb82z6LpyUVCebR0YVgfJmwGSDNS4llq6GznF7MxYZtYsp0WNvK7XLkYF1qxgRqyZqkqRhety0TbxWjgNmu++Uquroz5GjD2OaSzL472CvvncZIW1o7KdtjA6zhIVsmlhS/5GnV69vx+Lo3NjKbajPJw4TK0ogXcAQK60m8x5F6jgjF6tSc0lCndTCTSLLaU+grSFrFDQ4dqW810l0B6Ei6h5AsttNKf8m0/ZFX+kG4ZcJjIaR70gbTo5QQTSbicjAODahnlmy6hA1LeseO/1hphFmY7znZFHlqW2CDs+3z2MsUtl/1GwnVPJQ24fb6/9KTO4+iH3i43cOdLE6krWTKH+IzEP+YbF7JOnAEj67rdv1Ub151tjlsMuPxhnrn808hxYgsN gccrixWt jGlXSQfDpgvqcPMffTJ1/ru982G99fVb2hRh1ckUmqFkJesiT/taj/xj7t9/BNCgxjqui2OrSvM2LmJAVcKb782vRDxtz7CHk7g55eq8cyyyH9z2FWBtA2QDsYbyueaW5urGocw3/36CXIXtmOn7tm9onRHuW+ZUviBGwn5ytnoJm7eSflIa8KOsISQ== 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 Thu, Oct 24, 2024 at 10:23:49AM -0700, Shakeel Butt wrote: > On Thu, Oct 24, 2024 at 11:16:52AM GMT, Michal Hocko wrote: > > On Wed 23-10-24 23:57:12, Shakeel Butt wrote: > > > The memcg v1's charge move feature has been deprecated. There is no need > > > to have any locking or protection against the moving charge. Let's > > > proceed to remove all the locking code related to charge moving. > > > > > > Signed-off-by: Shakeel Butt > > > --- > > > -/** > > > - * folio_memcg_lock - Bind a folio to its memcg. > > > - * @folio: The folio. > > > - * > > > - * This function prevents unlocked LRU folios from being moved to > > > - * another cgroup. > > > - * > > > - * It ensures lifetime of the bound memcg. The caller is responsible > > > - * for the lifetime of the folio. > > > - */ > > > -void folio_memcg_lock(struct folio *folio) > > > -{ > > > - struct mem_cgroup *memcg; > > > - unsigned long flags; > > > - > > > - /* > > > - * The RCU lock is held throughout the transaction. The fast > > > - * path can get away without acquiring the memcg->move_lock > > > - * because page moving starts with an RCU grace period. > > > - */ > > > - rcu_read_lock(); > > > > Is it safe to remove the implicit RCU? > > Good question. I think it will be safe to keep the RCU in this patch and > in the followup examine each place and decide to remove RCU or not. I took a really quick look and based on it I believe it is safe. Shakeel, can you, please, check too and preferably keep your code intact. I think it's better to remove it all together, rather than do it in two steps. If we really need rcu somewhere, we can replace folio_memcg_lock()/unlock() with an explicit rcu_read_lock()/rcu_read_unlock(). Thanks!