From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B680E33B6E8 for ; Thu, 18 Dec 2025 13:00:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766062861; cv=none; b=ZfzkAdYANyzP9ClaxhO8noWqLcNVJXfTLGENNXFiahIkAkB4YknTX42hAU2rKJX6S/ZKf1hG2vu1VtCFpKkjF7F2YaJZOspTEEfTFc+3H2iwVPQn/XVbn7Z5rS9+vTsgB2230o9n7sa58t2z1CzJZAYUaEXCCrRLKnX5eaT/j7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766062861; c=relaxed/simple; bh=l8ozMIzwIt2g0HTicS4Uf8JKRpy3GZKapc/hx+niZoU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NY3MFK5Lg0keW9m5jxb6T8r72MFEuFphWp7wVAVYwzRv9xeNhepKruKYPqw6fMqh3H6QDn0V0NckpAvIaOglCEUOpok+Yh7cFUIPpwKe87khNlGzUn93BjSHkt8N3+cK9AfrX6c4XXPgWghxxTOK3JaU1b6OkktQZySGC4fTvn0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=i1ycgD8O; arc=none smtp.client-ip=209.85.222.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="i1ycgD8O" Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-8b2ec756de0so64138385a.3 for ; Thu, 18 Dec 2025 05:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1766062856; x=1766667656; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eyZ4aAJQTuFKnA4DRtBfOSsfoPJif64nSNk4YyPQ9Ro=; b=i1ycgD8O6XJpZbAHDwxjwvGsxHqbf72BrIqiZY3A3xqt6+mvKGtv2JmTHgUvwk2/Up OFGDUQj2+tHSwk3yYpSmg/L4LyrXBIqoeEK7aQjLGxNm/rbofRVMTTW3nIUETol2UUcz U+FTdBwgAOjQvFaKlDvDaiJ00lZRfQiHOZA4XMXnTvjPtYrWkK5cpCKMzZgjeVB12i8t 97GLJHDlqJiFjBlMYJ1XvZMnDj5gVVSJZI+Wu+E8Qy4gUHXlGdCekb624RkDfDQUaPLn Zmt73nDaQSY4KQivCIXTd58Kv3nJfvwOo6KBGG+L+P4xyEc1x6Gi+Dy2lcbnhjN7dIlz +JMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766062856; x=1766667656; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=eyZ4aAJQTuFKnA4DRtBfOSsfoPJif64nSNk4YyPQ9Ro=; b=MMXkxrBKfLcFS4wlRD90GymxtQTOmGwQ+II9zhsLN0OiOz0NtE10+bhv33PqmX/eGJ 6B+usUQJBFl0hHF3oyK+OBHTcpOHL0SSE2cVRyMm5ZXRXKaw0espra0p2G3qzpzFf1ds hnc8Xg32mp+TU/elvTElh4z6TqB8+nDfYpmsFoZsfxa9eOR0oKZ2bwLEF9BQadrhluGT Ir/hCfItAr+sLWBl8CG/IildvBLXkT9E7yFPQdNfjoyLZCthed8C+4pb7/h09KqFKI0I nok0OzEKj/JU3I2++mNHWvRpKecNmniyl7l/wTGx36zgQbhdsHenYNS3BeOPe/2aEcg1 IkSw== X-Forwarded-Encrypted: i=1; AJvYcCXit8lGPbJGd/gz+Z6/5G3uMxWfxpAaN9AHwYgTpTBUZpUYo9bBrpe0D2BxeuFDn/VNxwa9YqgUBGoG8Co=@vger.kernel.org X-Gm-Message-State: AOJu0YyivfOIZ/QGXvwDcNyHthRXlemUXQI780qbhZWHijnazZUCWme1 w97vO0gJ6xbl0H4YCqMMyPDqH4V61EqCJy4Wp6ghGfE2mPt3Tms8OFlleLrPPs3xGfo= X-Gm-Gg: AY/fxX6Bs+uERgH+COIXWdMdF0y3FX8/LXjx5MFmxlXTKnOl8q+cnwCio6VP05VG58L fWtWavBVLYwjpZ4xq8Bmd9myNiLj2WmGUYsPoQXxT3B2B7hyUf3DiS4AKneBG8Kexb6CvXjcSiQ oeUhv0/FFV5zBdRXqiaod80XVJ0tIeqt0x6wDzzgp6A819KBZWfLw7pmP/ndfz+NkAwUTasb95Z YW3TRoIG2+6PPyt+bcsp5pJTg5bEKqCl0aBApshkVQqYKnsLP7l2qyoU6B65fN4LE9ncIMU9IUy 1qlT8FhsBTJ2GiqPb/Gx32taFs/OU8jYRl2Nlxf77bDMoio0mFeJb5cLYM5A1xeMacUv6Ng9xz4 ziJo/67hgjxy6ri4f+kHiW/abPmJ9Z2qcBJ16r8FpxWvYxpDUrVtt1ngEwC8Q76V5EpMwexdAVe IZiuPZXGJQYUNkrg3ZUr45 X-Google-Smtp-Source: AGHT+IG6q+Bxs2SFIn60tS6Ai7tNXLIL/tEA/j0R5OH5fPvCoMnlyzZLehM9/wUFoyArtHFrlTTFZA== X-Received: by 2002:a05:620a:4010:b0:8a2:ef8:348c with SMTP id af79cd13be357-8bb399d9747mr2950051085a.2.1766062851153; Thu, 18 Dec 2025 05:00:51 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88c6089eda7sm15995056d6.34.2025.12.18.05.00.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Dec 2025 05:00:50 -0800 (PST) Date: Thu, 18 Dec 2025 08:00:46 -0500 From: Johannes Weiner To: Qi Zheng Cc: hughd@google.com, mhocko@suse.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, david@kernel.org, lorenzo.stoakes@oracle.com, ziy@nvidia.com, harry.yoo@oracle.com, imran.f.khan@oracle.com, kamalesh.babulal@oracle.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, chenridong@huaweicloud.com, mkoutny@suse.com, akpm@linux-foundation.org, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Muchun Song , Qi Zheng Subject: Re: [PATCH v2 23/28] mm: memcontrol: prepare for reparenting LRU pages for lruvec lock Message-ID: References: <6d643ea41dd89134eb3c7af96f5bfb3531da7aa7.1765956026.git.zhengqi.arch@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d643ea41dd89134eb3c7af96f5bfb3531da7aa7.1765956026.git.zhengqi.arch@bytedance.com> On Wed, Dec 17, 2025 at 03:27:47PM +0800, Qi Zheng wrote: > From: Muchun Song > > The following diagram illustrates how to ensure the safety of the folio > lruvec lock when LRU folios undergo reparenting. > > In the folio_lruvec_lock(folio) function: > ``` > rcu_read_lock(); > retry: > lruvec = folio_lruvec(folio); > /* There is a possibility of folio reparenting at this point. */ > spin_lock(&lruvec->lru_lock); > if (unlikely(lruvec_memcg(lruvec) != folio_memcg(folio))) { > /* > * The wrong lruvec lock was acquired, and a retry is required. > * This is because the folio resides on the parent memcg lruvec > * list. > */ > spin_unlock(&lruvec->lru_lock); > goto retry; > } > > /* Reaching here indicates that folio_memcg() is stable. */ > ``` > > In the memcg_reparent_objcgs(memcg) function: > ``` > spin_lock(&lruvec->lru_lock); > spin_lock(&lruvec_parent->lru_lock); > /* Transfer folios from the lruvec list to the parent's. */ > spin_unlock(&lruvec_parent->lru_lock); > spin_unlock(&lruvec->lru_lock); > ``` > > After acquiring the lruvec lock, it is necessary to verify whether > the folio has been reparented. If reparenting has occurred, the new > lruvec lock must be reacquired. During the LRU folio reparenting > process, the lruvec lock will also be acquired (this will be > implemented in a subsequent patch). Therefore, folio_memcg() remains > unchanged while the lruvec lock is held. > > Given that lruvec_memcg(lruvec) is always equal to folio_memcg(folio) > after the lruvec lock is acquired, the lruvec_memcg_debug() check is > redundant. Hence, it is removed. > > This patch serves as a preparation for the reparenting of LRU folios. > > Signed-off-by: Muchun Song > Signed-off-by: Qi Zheng > --- > include/linux/memcontrol.h | 26 ++++++++----------- > mm/compaction.c | 29 ++++++++++++++++----- > mm/memcontrol.c | 53 +++++++++++++++++++------------------- > 3 files changed, 61 insertions(+), 47 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 69c4bcfb3c3cd..85265b28c5d18 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -740,7 +740,11 @@ static inline struct lruvec *mem_cgroup_lruvec(struct mem_cgroup *memcg, > * folio_lruvec - return lruvec for isolating/putting an LRU folio > * @folio: Pointer to the folio. > * > - * This function relies on folio->mem_cgroup being stable. > + * The user should hold an rcu read lock to protect lruvec associated with > + * the folio from being released. But it does not prevent binding stability > + * between the folio and the returned lruvec from being changed to its parent > + * or ancestor (e.g. like folio_lruvec_lock() does that holds LRU lock to > + * prevent the change). Can you please make this separate paragraphs to highlight the two distinct modes of access? Something like this: Call with rcu_read_lock() held to ensure the lifetime of the returned lruvec. Note that this alone will NOT guarantee the stability of the folio->lruvec association; the folio can be reparented to an ancestor if this races with cgroup deletion. Use folio_lruvec_lock() to ensure both lifetime and stability of the binding. Once a lruvec is locked, folio_lruvec() can be called on other folios, and their binding is stable if the returned lruvec matches the one the caller has locked. Useful for lock batching. Everything else looks good to me. Thanks for putting so much effort into making these patches clean, well-documented, and the series so easy to review! Acked-by: Johannes Weiner