From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 22B71421254 for ; Tue, 4 Aug 2026 07:49:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785829747; cv=none; b=tZ3dgiZL00b1nmM7ksB7Ufqnh2jjDas/cgOKMuuIvkQuS4KU7utSl3I4lmJa6t1F6+c8O7LNEtE0k/B5dlQsgZbkxapz1hG4bGCgMz86iXOiZODb6i5sfgMCFKjwvfVIkWyp0MUNvbzIcmfeSccIat58cWcs5cbUtjCo/ISKejA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785829747; c=relaxed/simple; bh=6U+QT7E+ng2LNvIZ9Dt2uHbmOYHdgc63epHMecfQav0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t0ebA30j4S9xRHvSsi2tnNNGrfyyDXslzVd5arpBcybheCe0oAtveGxVRD3pVGQawR6qttp5pU2Zy2cms2RgHWYZW4nzhssFpKAY82TzWuRmjPyJ4kBj3Co1QubQtAObNd7aZ3N+9jpxAqiN+xBrJUt1Y5ib6VAgV1ky6rFfOvs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SZaqmEym; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SZaqmEym" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-ca957432c7fso2981386a12.1 for ; Tue, 04 Aug 2026 00:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785829744; x=1786434544; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=URYlG/xGVV5ysvUhV3ID8hokH80qFBSptYE9Jdvimh4=; b=SZaqmEym0CPqVcMML5r5Sd6Ah5p5Lzqv3uRFxb05Z6LoHbde6mChGugJq3xzPmmjNx wJd1xHSPi66URedRUDzPw4BCmMB2soZR+yuntCpt/bdcxT0rT7tEZBLaHUQZGNotQjtW tK9R1I9r1rdpLCxNUO3aGo/BYYMARU8y8dt++tt4lwEMpKK1ciDM16BcAahUH4pUPTOJ 1jkdogx7Gm9oC08uPZtY1Oe7thjaDSYDy5RnSFPp6dpqvM+qk7Pho2fO5VnHsFzsL15Q LVRHo1adGWSysgBIHOUcbVfU0EdKzPoqTOtirnKWaAz9PrhGQq4Ru++qG1Z7LBnT/xsm Gpew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785829744; x=1786434544; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=URYlG/xGVV5ysvUhV3ID8hokH80qFBSptYE9Jdvimh4=; b=h6joRcQZIPZD2Ua5LV45POOxrIiAnUwCjYAsYqo9UZA38nA5F+UK/w9HwOAwdrHOtr lvJcdvxH7S/dpiZWZbvSfhv3Y0YgkqVEUN/NXZIQK5Tnj6cWm9cwn3kjBb76qImbNsXs 389UUSm9VF1roanNUIYwANaUXC0HbrRRu/+A1g1fKW9juYNID7PyPwKDVd9lRTiNgsBA 9YuMh3XUqdp4IO/R7NRHQbDb8stRcfI6xa+PSmzkl5zasc3BAsIGulbhTgvh1jGDWaJE jHxlUsBjH6+KVWG+uq4DsY3ZjFmrAKnE5k/px/5LVTN9eDKmlIGDSGPl/CEfs4kj02tm G0KQ== X-Forwarded-Encrypted: i=1; AHgh+RoO9GMLC3nwUrpId0J4UNFK8wafJeDbOfz1QIve7+4og0DJJaV92H6iPoOB1N09yse78IrfpLblwAs/wyQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzXMKwNO0nwcMmcMoShDY7aYJDoWkBVyzA4QXfsFMivs1eUNugO LrbIhMqKNmWqNeaWUF33hmohX/CoRevCUNkMdBcFwq+fPGDh28+L2iBt X-Gm-Gg: AR+sD105TULQkRN0IuR1vzsZ4NVwo6Ui37lNsBo3o4NH6uBcevqL52xyeOf0FFh85OU uAVLpjO2V8saO+HubLFaSazPTVb8Y5WHc4T/YMlzZq/G52DRGNPjnH2mStA8ndnkGJ5dAjzykCJ kppmF1QeU5Li+XPqlSc0fh7yNXRes1F35/Scv0Amow5OnQTOQy9wZSuK+5YyztMfzBExw55IMAG s++z2ZYrHnsudxPzTBkpu/1W7CScmTkLhZJwX/30YSqT1S4vf326qs2BS6E0u2OXqU6YMqerMit znscdmNdt6R6UPUYiytzfbfpOJxQwvRexC0t8u+/OW00oi1LVu78s0lmSbxme9ovRj4LW9dVXuw DAq603qgurZe6X+oPJD8ocg5FkiDr/7yhoHhM9MJ0iCrYcJce6j5RNptzJ7KDUePg0eheKb2A8L YpFwQT6yoD2OlR+gYHlOWIPFuCkIEWr1yQJwTyEcGHqFLH0uPSlvWzvH6q6Xmw2bpgV951DZB1y KYpyKESWg4PxQ== X-Received: by 2002:a05:6a00:4b0d:b0:845:da74:5d7c with SMTP id d2e1a72fcca58-84ee480aa3fmr12133731b3a.32.1785829744273; Tue, 04 Aug 2026 00:49:04 -0700 (PDT) Received: from localhost.localdomain ([112.65.87.25]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84edc2d45e5sm4687101b3a.42.2026.08.04.00.48.52 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 04 Aug 2026 00:49:03 -0700 (PDT) From: Lian Wang To: Kairui Song via B4 Relay Cc: "Lian Wang (ProcessMission)" , linux-mm@kvack.org, Johannes Weiner , Muchun Song , Qi Zheng , Ying Huang , Chris Li , Baoquan He , Nico Pache , Usama Arif , Michal Hocko , Roman Gushchin , Shakeel Butt , David Hildenbrand , Lorenzo Stoakes , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Vlastimil Babka , Suren Baghdasaryan , Kemeng Shi , Nhat Pham , Youngjun Park , Zi Yan , Gregory Price , "Matthew Wilcox (Oracle)" , Baolin Wang , Ryan Roberts , Dev Jain , Lance Yang , Hugh Dickins , SeongJae Park , David Rientjes , Yu Zhao , Vernon Yang , Zicheng Wang , Chen Ridong , Tal Zussman , Kairui Song , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Kairui Song Subject: Re: [PATCH RFC 08/15] mm/memcg: add folio-based lruvec live helper Date: Tue, 4 Aug 2026 15:48:03 +0800 Message-ID: <20260804074844.99770-1-lianux.mm@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260804-mglru-fg-v1-8-4d8dad39dad6@tencent.com> References: <20260804-mglru-fg-v1-0-4d8dad39dad6@tencent.com> <20260804-mglru-fg-v1-8-4d8dad39dad6@tencent.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Lian Wang (ProcessMission)" Hi Kairui, I am trying to understand the lifetime and accounting guarantee here, and would appreciate your guidance. My understanding is that RCU protects the lruvec lifetime, but by itself does not stabilize the folio->lruvec association across memcg deletion and reparenting. Could folio_inc_lru_refs() obtain the child lruvec here, then race with __lru_gen_reparent_memcg(), and finally account the generation move to the old child after the folio and its counters have moved to the parent? The opposite ordering also seems possible: this helper observes css_is_dying() and selects the parent while the folio is still accounted to the child. Is there another invariant that closes these races? If my understanding is correct, it seems the helper guarantees a live object, but not a stable binding, and the lockless promotion path may need validation/retry or explicit synchronization with reparenting. If I have misunderstood the intended synchronization here, please feel free to ignore this concern. Thanks, Lian On Tue, 04 Aug 2026 03:47:04 +0800 Kairui Song via B4 Relay wrote: > From: Kairui Song > > Add a helper that resolves a stable lruvec for a folio under RCU > without taking the lruvec lock. It takes a folio directly so the > lruvec lookup happens inside the RCU read-side critical section, > which a lruvec-based interface cannot guarantee. > > The lock-taking variant now inlines the ancestor walk instead of > calling a separate helper. > > No functional change. > > Signed-off-by: Kairui Song > --- > include/linux/memcontrol.h | 38 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 38 insertions(+) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 68f363000d7f..ea0111392b9b 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -1506,6 +1506,44 @@ static inline void lruvec_lock_irq(struct lruvec *lruvec) > spin_lock_irq(&lruvec->lru_lock); > } > > +/** > + * folio_lruvec_live_get - get a live lruvec for a folio under RCU > + * @folio: the folio > + * > + * Computes @folio's lruvec and walks up to the nearest live ancestor > + * if the folio's memcg is dying. Must be paired with > + * folio_lruvec_live_put(). > + * > + * Return: the live lruvec, with rcu_read_lock held. > + */ > +static inline struct lruvec *folio_lruvec_live_get(struct folio *folio) > +{ > +#ifdef CONFIG_MEMCG > + struct lruvec *lruvec; > + struct pglist_data *pgdat; > + struct mem_cgroup *memcg; > + > + rcu_read_lock(); > + lruvec = folio_lruvec(folio); > + pgdat = lruvec_pgdat(lruvec); > + memcg = lruvec_memcg(lruvec); > + while (unlikely(memcg && css_is_dying(&memcg->css))) { > + memcg = parent_mem_cgroup(memcg); > + lruvec = mem_cgroup_lruvec(memcg, pgdat); > + } > + return lruvec; > +#else > + return folio_lruvec(folio); > +#endif > +} > + > +static inline void folio_lruvec_live_put(struct lruvec *lruvec) > +{ > +#ifdef CONFIG_MEMCG > + rcu_read_unlock(); > +#endif > +} > + > static inline struct lruvec *lruvec_live_lock_irq(struct lruvec *lruvec) > { > #ifdef CONFIG_MEMCG > > -- > 2.55.0 > > > Sent using hkml (https://github.com/sjp38/hackermail)