From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 6BBA836C5A0 for ; Wed, 18 Mar 2026 08:17:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773821827; cv=none; b=SVXfEt34AZMkwlxdSJ3lpWe/IHSpBuG7yJqVRXSDVGVEvxHvxTHrVRmTKPS3HP9iUpCqC7lBXgc+QsLUBtKykFtU9JPfxEVC0cldxWtWcyFc8OYqwh5qqXa5nWWwViq2pyuRNZRa0QsMVT/wt/dSr448z50Gxrr7g9X+zGuiJ0c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773821827; c=relaxed/simple; bh=2ZfPwLnmK0B3DLbDeQaS/3wp2ULfB71nBpYCpytL1jE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=f9yywipOSWWtcCgULoB7+CftTwKFJdgfUbBpkWlLLSqyHr/UDzJWQ1xbhC80I/dwxmLG21e2QEF0yYME6JFAIusfSoqsmZT7zK0WBQ/nJyVyQCuCRQwlDVsI/3IThm0f458tWANAMtrMbAtfYIG2HwXZ/9L3NNuvBCJCfNsboRA= 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=M9i517lh; arc=none smtp.client-ip=209.85.210.169 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="M9i517lh" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-82a73593410so80586b3a.1 for ; Wed, 18 Mar 2026 01:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773821826; x=1774426626; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1WLb3z75FyW4V0wEi4APXz2nEEb3hslQr/9K17bOZZ0=; b=M9i517lhZVSD8Wq7Ax8a7+Z1T4YcD+viqy3WM/MM6FJBuNe0N9sLhhJpu2AgV88pkG 63uUL/KfN5Q/MyyiM1xn7r/AYTiwITWdyW5a7GTonp6cTKAd9nWoqIVvpdaEfgI9aSTF TowIb76Zg1napaoGZ6HEQ7RXXxSDI093Hact/lBj1zRCbNVW5AH0xclVf5ckhD3AA2bp PnqVkA4owCEnyzoyKfgjgO/l0nYxfE1MB9LY//8b0/iQ3Q/qTSXL6hlGzzjrDbYzHYq+ gk0Uc5LD+Ddoyx9plYpFKOstsMZcUXdMyhYRH1OtinWqLyko2iW1FFtp9xAU8/PwLkBn Dk5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773821826; x=1774426626; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1WLb3z75FyW4V0wEi4APXz2nEEb3hslQr/9K17bOZZ0=; b=X/tuHQrJuvl2wxMV7mkEq96ES6cdBP9JWxS+93pZ5fvHFtKywfBNDN9s3nm3iEBwNt l9JkE9Px2ArboHzy5wCcsZESWnZfpeCl5eelMjqZ0msL7WnOcSMPSH3yIZP9vT7ylBMS 4NOf/P31XAp3+6OY9FueDfIoY2G+waKcSYFYDWNbeRaqjGf943s+kFDJ/oRzO0Rbzt8Y P4w3c8HyL2TvnCg4D/9Xv9o3ksvpI36nxoCpH7agZFSVfMItYOcIClBePNFHYXnDDjQU wUq+8yz8rLr90uM9BvKCyUnNn+5uXH/JqZ3F4iVvSqzDwzs5lYdETEqilq4u2tst94Qy ENKA== X-Forwarded-Encrypted: i=1; AJvYcCXY9lh0jQdXGZjRnxy2TQ+AgLZclMOP1i62q3H3YXTD/xidAzMx6XJcXBx629q3bOLLB68rWKYf48bRMaA=@vger.kernel.org X-Gm-Message-State: AOJu0YwSHTVg6/yfnd67ve9CiSUCLTW6FuAoG/VXfiNx4bCdd38cI9U8 b3qRIPJWklWulmUzWggoNrWiWq9f6o8fFw1p9I+A8Efszz+AqXp2dUA5e3snxLRy+lqBwA== X-Gm-Gg: ATEYQzwRXeDDliIgEuvFQ6UgUurlyB0Nn1SL3eu1gtzlBu4/E0BWUdowi5KA9scFygF Tf9TgV07YRRqv8hbNpogd4gAucqVCbSo/v1JjNhXFKoZjsz4myXknBZosAUcQUxQIJKPuCB8jo3 tSkd6jzXRGckqGhuuyRJflu09NZ+WTeKMole8sljzgIAcEFwaVLouo+NLzUrgwjMqxVqYIvIARV IKozk86e0dDUy80AljvM8s0h5hXErjbg5r1mR7gpaebex9/QjIScZKQAe+bHXSSKkNONrP0FPEZ BaEdTSzXidBKJjxTGRg6I1yVhNpY3a5+1TpyDxJiN0TYYtHenzFf6sRVDyeGoiQEvuWBYoD3NBP k+9u8wfMswzgVHVx9bYV2Fy5/lsA3FnNQYShWp/lSF0c1wt2dmYyPRtHYWIF/EstOdew/Zx6PLP RyKfN13wls44MlgI8Pfv6h1OysMoDSlhTzExtnfenzgmdRorldavQg22CUavF/H55ajZqyo842Y G1NHuXlER/B0G4p2N0MhTLTgymHMjUpg2SUQpKcZZL9 X-Received: by 2002:a05:6a00:198c:b0:82a:110b:e212 with SMTP id d2e1a72fcca58-82a6a8ea5c3mr2384304b3a.0.1773821825209; Wed, 18 Mar 2026 01:17:05 -0700 (PDT) Received: from ?IPV6:2408:84e2:440:5e9c:59ce:3c05:93bc:f8f8? ([2408:84e2:440:5e9c:59ce:3c05:93bc:f8f8]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82a6af06bd7sm1822165b3a.0.2026.03.18.01.17.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Mar 2026 01:17:04 -0700 (PDT) Message-ID: <8c01a707-f798-4649-8441-d82dd0dac7b9@gmail.com> Date: Wed, 18 Mar 2026 16:16:58 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4] mm/mglru: fix cgroup OOM during MGLRU state switching To: Barry Song <21cnbao@gmail.com> Cc: Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jialing Wang , Yafang Shao , Yu Zhao , Kairui Song , Bingfang Guo , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260318-b4-switch-mglru-v2-v4-1-1b927c93659d@gmail.com> Content-Language: en-US From: Leno Hou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/18/26 3:16 PM, Barry Song wrote: > On Wed, Mar 18, 2026 at 11:29 AM Leno Hou via B4 Relay > wrote: >> >> From: Leno Hou > > [...] > >> >> diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h >> index ad50688d89db..1f6b19bf365b 100644 >> --- a/include/linux/mm_inline.h >> +++ b/include/linux/mm_inline.h >> @@ -102,6 +102,12 @@ static __always_inline enum lru_list folio_lru_list(const struct folio *folio) >> >> #ifdef CONFIG_LRU_GEN >> >> +static inline bool lru_gen_draining(void) >> +{ >> + DECLARE_STATIC_KEY_FALSE(lru_drain_core); >> + >> + return static_branch_unlikely(&lru_drain_core); >> +} > > Can we name it lru_gen_switch() or lru_switch? > Since “drain” implies disabling MGLRU, the operation > could just as well be enabling it. Also, can we drop > the _core suffix? OK. Next V5 patch will be: +static inline bool lru_gen_switching(void) +{ + DECLARE_STATIC_KEY_FALSE(lru_switch); + + return static_branch_unlikely(&lru_switch); +} > > >> #ifdef CONFIG_LRU_GEN_ENABLED >> static inline bool lru_gen_enabled(void) >> { >> @@ -316,6 +322,11 @@ static inline bool lru_gen_enabled(void) >> return false; >> } >> >> +static inline bool lru_gen_draining(void) > > lru_gen_switching()? > >> +{ >> + return false; >> +} >> + >> static inline bool lru_gen_in_fault(void) >> { >> return false; >> diff --git a/mm/rmap.c b/mm/rmap.c >> index 6398d7eef393..0b5f663f3062 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -966,7 +966,7 @@ static bool folio_referenced_one(struct folio *folio, >> nr = folio_pte_batch(folio, pvmw.pte, pteval, max_nr); >> } OK. I'll be add following ducumentation that just you said. /* When LRU is switching, we don’t know where the surrounding folios are. —they could be on active/inactive lists or on MGLRU. So the simplest approach is to disable this look-around optimization. */ >> - if (lru_gen_enabled() && pvmw.pte) { >> + if (lru_gen_enabled() && !lru_gen_draining() && pvmw.pte) { > > Ack. When LRU is switching, we don’t know where the > surrounding folios are—they could be on active/inactive > lists or on MGLRU. So the simplest approach is to > disable this look-around optimization. > But please add a comment here explaining it. > > >> if (lru_gen_look_around(&pvmw, nr)) >> referenced++; >> } else if (pvmw.pte) { >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 33287ba4a500..88b9db06e331 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -886,7 +886,7 @@ static enum folio_references folio_check_references(struct folio *folio, >> if (referenced_ptes == -1) >> return FOLIOREF_KEEP; >> >> - if (lru_gen_enabled()) { documentation as following: /* * During the MGLRU state transition (lru_gen_switching), we force * folios to follow the traditional active/inactive reference checking. * * While MGLRU is switching,the generational state of folios is in flux. * Falling back to the traditional logic (which relies on PG_referenced/ * PG_active flags that are consistent across both mechanisms) provides * a stable, safe behavior for the folio until it is fully migrated back * to the traditional LRU lists. This avoids relying on potentially * inconsistent MGLRU generational metadata during the transition. */ >> + if (lru_gen_enabled() && !lru_gen_draining()) { > > I’m curious what prompted you to do this. > > This feels a bit odd. I assume this effectively makes > folios on MGLRU, as well as those on active/inactive > lists, always follow the active/inactive logic. > > It might be fine, but it needs thorough documentation here. > > another approach would be: > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 33287ba4a500..91b60664b652 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -122,6 +122,9 @@ struct scan_control { > /* Proactive reclaim invoked by userspace */ > unsigned int proactive:1; > > + /* Are we reclaiming from MGLRU */ > + unsigned int lru_gen:1; > + > /* > * Cgroup memory below memory.low is protected as long as we > * don't threaten to OOM. If any cgroup is reclaimed at > @@ -886,7 +889,7 @@ static enum folio_references > folio_check_references(struct folio *folio, > if (referenced_ptes == -1) > return FOLIOREF_KEEP; > > - if (lru_gen_enabled()) { > + if (sc->lru_gen) { > if (!referenced_ptes) > return FOLIOREF_RECLAIM; > > This makes the logic perfectly correct (you know exactly > where your folios come from), but I’m not sure it’s worth it. > > Anyway, I’d like to understand why you always need to > use the active/inactive logic even for folios from MGLRU. > To me, it seems to work only by coincidence, which isn’t good. > > Thanks > Barry Hi Barry, I agree that using !lru_gen_draining() feels a bit like a fallback path. However, after considering your suggestion for sc->lru_gen, I’m concerned about the broad impact of modifying struct scan_control.Since lru_drain_core is a very transient state, I prefer a localized fix that doesn't propagate architectural changes throughout the entire reclaim stack. You mentioned that using the active/inactive logic feels like it works by 'coincidence'. To clarify, this is an intentional fallback: because the generational metadata in MGLRU becomes unreliable during draining, we intentionally downgrade these folios to the traditional logic. Since the PG_referenced and PG_active bits are maintained by the core VM and are consistent regardless of whether MGLRU is active, this fallback is technically sound and robust. I have added detailed documentation to the code to explain this design choice, clarifying that it's a deliberate transition strategy rather than a coincidence." Best Regards, Leno Hou