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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 09B89CD4F26 for ; Fri, 26 Jun 2026 07:09:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7478D6B0005; Fri, 26 Jun 2026 03:09:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D19C6B0099; Fri, 26 Jun 2026 03:09:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59C1A6B009B; Fri, 26 Jun 2026 03:09:21 -0400 (EDT) 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 274A46B0005 for ; Fri, 26 Jun 2026 03:09:21 -0400 (EDT) Received: from smtpin28.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 930F38D656 for ; Fri, 26 Jun 2026 07:09:20 +0000 (UTC) X-FDA: 84921187680.28.8916CD4 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf03.hostedemail.com (Postfix) with ESMTP id DC0C120011 for ; Fri, 26 Jun 2026 07:09:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=hT1d3M4U; spf=pass (imf03.hostedemail.com: domain of harry@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=harry@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=none; t=1782457759; b=M9PSX/ADzmNtZ/+nWqnQl8FHN11zJbUy/YbSNMXk+rmugEljlqozS9SoH5JTBcU8/2xc6C dIrWhHFlbbN6760G0d/mX1hvMtTbwpxEWNe7psWUEN36yYRhSIFcUNN/rRwmMHdb51oi+9 4h0a+d/Z0I/3do7FEMpg6y1M5IbraIU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1782457759; 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=qqBlcdRV2i1go9GKmpopie5fik3FLtofH/AmE7bi9jg=; b=Wlju8redaYBbhQpbO5cxIRWzrS6X/Nr7ntsr5Si/zWUpnJDuw7mjZRKby7WBbhR9O/yRrY +F2G8KVq/fQPP3c05RLuvrqxnkTjnkcPeOcmPC01lF2CRLMe2rNgmvhTC3A2WNXIgt5dgl 6bKqX04g0LL8E5VPMBeGyBSKgdFpH3Q= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=hT1d3M4U; spf=pass (imf03.hostedemail.com: domain of harry@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=harry@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id C6AF2439E8; Fri, 26 Jun 2026 07:09:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21BE61F000E9; Fri, 26 Jun 2026 07:09:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782457757; bh=qqBlcdRV2i1go9GKmpopie5fik3FLtofH/AmE7bi9jg=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=hT1d3M4UQb4Ned3clUpZ462ztJ/9kxePVvODhtD8S8vFXeINMJnbXP21x+Pudhbpr 5gaFB9x1cQxuIvVIjhW9Hkqv/pG8Wue4pOI3NN4InezVSUFyH595Gw4zPAP7JHuFG+ MeeSZAm5XukCvZ6WLuFLXD2+n3Jiq2zCd3MSrVApNI3c4YPawm5aAzGY5UPp0BzTF/ cL5oaPb4KY8qIQKX0X3xdpBe+gu9LcNGxrJkfIOcRgjPEGrqKOgO6VLZQ4ruPfbvzs qGxS7Uz31U4MwAdxQA8JDGr/zH+valy4AphWBEiSfAZW5wW7lbUAwo2s6nJD0aSAMc HdI1rpyMFQpEw== Message-ID: <9e42c598-972e-4f66-a5be-e18b81274a6e@kernel.org> Date: Fri, 26 Jun 2026 16:09:08 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm: mglru: fix stale batch updates after memcg reparenting To: Qi Zheng , Johannes Weiner Cc: akpm@linux-foundation.org, david@kernel.org, kasong@tencent.com, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, muchun.song@linux.dev, peiyang_he@smail.nju.edu.cn, mhocko@kernel.org, roman.gushchin@linux.dev, ljs@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng , stable@vger.kernel.org References: <20260625151554.55105-1-qi.zheng@linux.dev> <4c7b0c46-14f0-4a62-893e-e50714e09b74@linux.dev> <46ac28bf-5be1-4600-b522-0a1aa76c28e6@kernel.org> <08cf8972-6cfc-4452-9a3c-88e0368dbbf9@linux.dev> <90fd5300-1016-42e7-abad-08ad85fb62b4@linux.dev> <5a0c6597-6b96-4781-a71b-fd1298b2b7bb@kernel.org> Content-Language: en-US From: Harry Yoo In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Vt7pX0ay0nseJq7UGWnJriZK" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DC0C120011 X-Stat-Signature: rfzfurunaycw65ytygiqrjykdzimc4ci X-HE-Tag: 1782457758-745035 X-HE-Meta: U2FsdGVkX1+IS89BWrVp90WHIsDKc4uGmKPq9wCUTX0OMbHW9K7BAdjFYc7Bq4OM26CyNMTGyUscV/F30BK73cEHHYHgIcyNnHIK/bcMaqXlCZjlabK6w77fnkwIjfPErFjXNa66yHRa5J8jDQnJQYxAIWBNRqCZm15vY/5OpOHoHhpRzXbEikTc3oNHYGWb1kW7gf/CFr12otY7wJGkdy7bBM9osyeQUBK8TlwKUndc5/roj0Hh61gS3PPNzkIoLNxaZUa93zTVQLu0++l+ypG/U59qevQZ1t2K3fIpFZlMECs4CY3NbobXPsMo4dd8Kl4+KRyGraeuBxsaWkHTqZgGD5Zb9Uk+xn5Lz4Ewvmgl5IEkugYrL3QBOk6GNmaM3mxy69Gb6vNBa8JK/hZHidJsEMr84m+ArLJaQPgoJT8er6Vdwm+uuJ0N+h0Qvxt7cUx4r7zGPL/n19GUHOASRueGih6Iw8cLf2zzWb8XsnoDDVKwnFmyc+Z/J59gbCTflHWaHc40+ps5y8TgzXU+jt6ihU62yloPmIijhA6vAysP3kjjQkB09YvylQTIwndstBjOj2KtbXL8RmGYoCiD9MziISj3F8+x4HL8LhKAw58Aqq0CbolfqCV6HyZpk8SRfq4K2zll5WGaHownFWr2vz0UWSccIVIULdYQvdzyQn6TbXBNWGvqeZIgD9VkZaMaK86fcBo4eMQV0gIVXs71cxD+8wHUw2A5yidz9Ui5Pd6Bj06BkGEHDKU7Cx+mMD3+BmyQ80ICKYy8wgGeodo15vZDEf+jDt/ufwibV4QGFmJnvAO2dzFqpo3cLsnaifODjxc8XGGOMhCIkbgQ+CnhItmsn7yzRuAvNGg0aWcpK35s0wFY8Cw5Z3tIIN6ryjX99M346Ii7fVlnK/DhZoeaTxyKhbnuLG+inRfDq1FSDHI1JJ0ZM7u0PbusItzLPvfgyx7TFu0lKKkFjJvxkon klLLnzTN gLV7NLywUmO1DAHhlks2A3xLx0APsfCtYO4UT+hxZNq1+iTRqpPv7LPBU3uoARmgXagEt2slMRGe644HvJG8xnknw8D/FEwTTQA+U1jQVbiNFh3eA8HMj0PwPNhLH0KQt7iOt0G6ek72pbZRKIhb8ntXrOrv0xGAoLqMzAT64sVDTCY8yzZb+V1wWB4ngthzHBviMJuvDhGaNnVagQlYom5lpWo0WLdnA4kW5EcSsoP0YQAL/G3rfMjdgLFKkgl1UWutTk9CQtju8VHwmO+62x7nNTOclj0WuVsM5X3SlDsBcmsDWNnGdpx72y/TrSy2eGM38i7FCp1Z5SjV8wnUTzDqXs7CDZ+1cs01mUVC64jOveq0k/OhjwgNk2NdAeK3kN3LoHa//LP6pc6HX6mCfxW3WR6M+MYJjB+IYAMTUXrPgIAIM9DNdLN9Isgh6/uu9Nu9ZpgCWsHckRhM= Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Vt7pX0ay0nseJq7UGWnJriZK Content-Type: multipart/mixed; boundary="------------nEc0mtnD69zDGI1M80H7UGcy"; protected-headers="v1" From: Harry Yoo To: Qi Zheng , Johannes Weiner Cc: akpm@linux-foundation.org, david@kernel.org, kasong@tencent.com, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, muchun.song@linux.dev, peiyang_he@smail.nju.edu.cn, mhocko@kernel.org, roman.gushchin@linux.dev, ljs@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng , stable@vger.kernel.org Message-ID: <9e42c598-972e-4f66-a5be-e18b81274a6e@kernel.org> Subject: Re: [PATCH v3] mm: mglru: fix stale batch updates after memcg reparenting References: <20260625151554.55105-1-qi.zheng@linux.dev> <4c7b0c46-14f0-4a62-893e-e50714e09b74@linux.dev> <46ac28bf-5be1-4600-b522-0a1aa76c28e6@kernel.org> <08cf8972-6cfc-4452-9a3c-88e0368dbbf9@linux.dev> <90fd5300-1016-42e7-abad-08ad85fb62b4@linux.dev> <5a0c6597-6b96-4781-a71b-fd1298b2b7bb@kernel.org> In-Reply-To: --------------nEc0mtnD69zDGI1M80H7UGcy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/26/26 4:04 PM, Qi Zheng wrote: > On 6/26/26 2:48 PM, Harry Yoo wrote: >> On 6/26/26 3:24 PM, Qi Zheng wrote: >>> On 6/26/26 12:59 PM, Harry Yoo wrote: >>>> On 6/26/26 1:48 PM, Qi Zheng wrote: >>>>> On 6/26/26 12:43 PM, Harry Yoo wrote: >>>>>> On 6/26/26 11:27 AM, Qi Zheng wrote: >>>>>>> On 6/26/26 2:41 AM, Johannes Weiner wrote: >>>>>>>> On Thu, Jun 25, 2026 at 11:15:54PM +0800, Qi Zheng wrote: >>>>>>>>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>>>>>>>> index 35c3bb15ae96..1ec8c23c72b9 100644 >>>>>>>>> --- a/mm/vmscan.c >>>>>>>>> +++ b/mm/vmscan.c >>>>>>>>> @@ -3262,10 +3262,44 @@ static void update_batch_size(struct >>>>>>>>> lru_gen_mm_walk *walk, struct folio *folio, >>>>>>>>> walk->nr_pages[new_gen][type][zone] +=3D delta; >>>>>>>>> } >>>>>>>>> +#ifdef CONFIG_MEMCG >>>>>>>>> +static struct lruvec *lock_batch_lruvec(struct lruvec *lruvec)= >>>>>>>>> +{ >>>>>>>>> + struct pglist_data *pgdat =3D lruvec_pgdat(lruvec); >>>>>>>>> + struct mem_cgroup *memcg =3D lruvec_memcg(lruvec); >>>>>>>>> + >>>>>>>>> + rcu_read_lock(); >>>>>>>> >>>>>>>> Where is this unlocked? >>>>>>> >>>>>>> The lruvec_unlock_irq() in reset_batch_size() will handle the >>>>>>> unlocking. >>>>>>> >>>>>>>>> + /* >>>>>>>>> + * The memcg can be NULL when the memory controller is >>>>>>>>> disabled. >>>>>>>>> + * Otherwise, the caller keeps the memcg owning @lruvec >>>>>>>>> alive. >>>>>>>>> + */ >>>>>>>>> + if (!memcg || !css_is_dying(&memcg->css)) >>>>>>>>> + goto lock; >>>>>>>>> + >>>>>>>>> + do { >>>>>>>>> + memcg =3D parent_mem_cgroup(memcg); >>>>>>>>> + } while (memcg && css_is_dying(&memcg->css)); >>>>>>>>> + lruvec =3D mem_cgroup_lruvec(memcg, pgdat); >>>>>>>> >>>>>>>> while (unlikely(memcg && css_is_dying(&memcg->css))) { >>>>>>>> memcg =3D parent_mem_cgroup(memcg); >>>>>>>> lruvec =3D mem_cgroup_lruvec(memcg, pgdat); >>>>>>> >>>>>>> There is no need to acquire the lruvec before finding the first >>>>>>> non-dying memcg. >>>>>> >>>>>> struct pglist_data *pgdat =3D lruvec_pgdat(lruvec); >>>>>> struct mem_cgroup *memcg =3D lruvec_memcg(lruvec); >>>>>> >>>>>> rcu_read_lock() >>>>>> >>>>>> while (unlikely(memcg_is_dying(memcg))) >>>>>> memcg =3D parent_mem_cgroup(memcg); >>>>>> >>>>>> lruvec =3D mem_cgroup_lruvec(memcg, pgdat); >>>>> >>>>> If the first memcg is already non-dying, there's no need to re-acqu= ire >>>>> the lruvec. ;) >>>> >>>> Oh, right :) >>>> >>>> Hmm but I still think Johannes' suggestion makes the code cleaner. >>> >>> I don't have a strong preference on which of the two coding styles is= >>> more readable. BTW, is there any kernel documentation I could refer t= o >>> for this? >> >> I don't think there's a coding style guide that specifically >> mentions this. Just thought it's cleaner because it merges if (...) go= to >> lock; and do-while into a single while loop. >> >>>> Observing a dying cgroup should be rare anyway, it's worth focusing >>>> more on readability? >>> >>> While it's rare to encounter consecutive dying memcgs, it can still >>> happen, right? >> >> But is worth saving a few instruction in a basic block that is >> unlikely() to be executed? >=20 > I don't have a strong opinion here. Hi Johannes, I'll leave the decisio= n > up to you. If necessary, I can send out the v4. >=20 >> >> I'm not a memcg maintainer myself, though. just my 2 cents. >=20 > I'd like to express my gratitude for your reviews, and especially > for your invaluable help with the earlier dying memcg work! No problem, likewise to you and Muchun for invaluable work ;) --=20 Cheers, Harry / Hyeonggon --------------nEc0mtnD69zDGI1M80H7UGcy-- --------------Vt7pX0ay0nseJq7UGWnJriZK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQQ1ub6gR5ogjaKRmOGXBN6rc5S1gUCaj4llAAKCRCGXBN6rc5S 1uTzAQC/4GFtaHGc7IlIYLUD17u7FA/tCggxzc848KvmYdxLhQD+PAZEqf4/fXS9 HMlcUHymSJ42Txrn7IAv81yrr7EjgQ0= =YEci -----END PGP SIGNATURE----- --------------Vt7pX0ay0nseJq7UGWnJriZK--