From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-138.mta0.migadu.com [91.218.175.138]) (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 4072E3B4E8B for ; Thu, 20 Aug 2026 07:31:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.138 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787211081; cv=none; b=Prgl1eWmQPV8pg4af8YcBQ+c7Kq/BNdOlQQD654UcOFSnf0vMbUy265+uPMxvzhQOcVsYTvN/tfbMO/KgdXQwadY517BU8Jk2z18w59L/gtCGxR/ZE3dweIivG9oo+zHZfGc8D7VILnqAK5ySfQPJPQB/v4hcfKbsn3DsgnOG3A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787211081; c=relaxed/simple; bh=2Q6w1Z3LbClB6sJ7/K3H1n0fkpRB+6xPKkq/JisKM60=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hQsZi0L5QHnSzpY92u7yxUyrmwLTl9hGI7hUbbVADfuYWb3zU7RddmL6hMd6MnE9ejeIijdvAXiXk7xJWuRFG0q5GKM/U0TMZrYMujpJRYrPoampMryQ5KWzCLQH7/TLkoU6mhX+vKe87s9kgeRC8SEEKlwKlAtlfqB4dFAyI9M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=kFEkMIGL; arc=none smtp.client-ip=91.218.175.138 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="kFEkMIGL" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=2Q6w1Z3LbClB6sJ7/K3H1n0fkpRB+6xPKkq/JisKM60=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787211076; v=1; x=1787815876; b=kFEkMIGL3EtQKQIPOfdd0+AjFUIrGLm+w6/B8pCgU3EoRrnUeHd4awsi0p9/IIJ0CIjpgFfq q/J9FHCsoevZjNfLpI/bzgh2KnL7IkSG1Wjx8xQ17EzOEpVS2m8p1yTqIB5clWIU5LwJtXX1lLg vXhecGIGO4rnu9mk6R1+iRhw= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [10.63.107.123] (14.29.108.92) by smtp.migadu.com with ESMTPS id 90fcd31e707e72bc; Thu, 20 Aug 2026 07:31:16 +0000 X-Mizu-Trace-ID: 90fcd31e707e72bc X-Migadu-Flow: FLOW_OUT Message-ID: Date: Thu, 20 Aug 2026 15:31:06 +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: [RFC PATCH] mm/mglru: preserve inactive placement when enabling MGLRU To: Barry Song Cc: Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Brian Geffon , "Jan Alexander Steffens (heftig)" , Steven Barrett , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen References: <20260813110230.2124785-1-ridong.chen@linux.dev> From: Ridong Chen In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/2026 10:31 AM, Barry Song wrote: > On Fri, Aug 14, 2026 at 10:22 AM Ridong Chen wrote: >> >> >> >> On 8/13/2026 7:37 PM, Barry Song wrote: >>> On Thu, Aug 13, 2026 at 7:24 PM Barry Song wrote: >>>> >>>> On Thu, Aug 13, 2026 at 7:02 PM Ridong Chen wrote: >>>>> >>>>> From: Ridong Chen >>>>> >>>>> When the LRU is switched to MGLRU (echo y > /sys/kernel/mm/lru_gen/ >>>>> enabled), fill_evictable() re-inserts every folio via >>>>> lru_gen_add_folio(..., false). With reclaiming hardcoded to false, an >>>>> inactive anonymous folio (no PG_active, not in the swapcache) takes the >>>>> "gen = MIN_NR_GENS" branch in lru_gen_folio_seq() and is seeded at >>>>> seq = max_seq - 1, which lru_gen_is_active() treats as active. Its >>>>> inactive placement is lost and NR_INACTIVE_ANON is folded into >>>>> NR_ACTIVE_ANON. >>>>> >>>>> Pass reclaiming=!active so a folio from an inactive list is seeded into >>>>> an older generation. Folios from the active list carry PG_active and >>>>> hit the first branch either way, so they are unchanged. >>>>> >>>>> Tested on x86_64, next-20260812, 2G VM + 1G swap, ~1.5G anon pushed onto >>>>> the inactive list before enabling MGLRU: >>>>> >>>>> Active(anon) Inactive(anon) >>>>> before switch (legacy) 2952 1548792 kB >>>>> after `echo y`, unpatched 1552052 0 kB >>>>> after `echo y`, patched 15144 1536636 kB >>>>> >>>>> Inactive file folios stay inactive either way (NR_INACTIVE_FILE is >>>>> preserved). >>>>> >>>>> Fixes: 354ed5974429 ("mm: multi-gen LRU: kill switch") >>>>> Assisted-by: Claude:claude-opus-4-8 >>>>> Signed-off-by: Ridong Chen >>>>> --- >>>>> mm/vmscan.c | 7 ++++++- >>>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>>>> index 94fc4f25e99f..2befc8d7dd3f 100644 >>>>> --- a/mm/vmscan.c >>>>> +++ b/mm/vmscan.c >>>>> @@ -5319,7 +5319,12 @@ static bool fill_evictable(struct lruvec *lruvec) >>>>> VM_WARN_ON_ONCE_FOLIO(folio_lru_gen(folio) != -1, folio); >>>>> >>>>> lruvec_del_folio(lruvec, folio); >>>>> - success = lru_gen_add_folio(lruvec, folio, false); >>>>> + /* >>>>> + * Keep a folio from the inactive list inactive: >>>>> + * pass reclaiming=!active so it is not seeded as >>>>> + * active. See lru_gen_folio_seq(). >>>>> + */ >>>>> + success = lru_gen_add_folio(lruvec, folio, !active); >>>> >> >> Hi Barry, Thank you for your reply. >> >>>> This is a very interesting use of the reclaim argument, as it is not >>>> intended to serve this MGLRU switch purpose. It is really only meant >>>> for `folio_rotate_reclaimable()`. >>>> >> >> Yeah, I realize tying the reclaim argument to the MGLRU switch is a bit of a >> hack, since it was really only designed for folio_rotate_reclaimable(). That >> said, I'm not blind to it, I just posted an RFC patch to get the discussion >> rolling and see what people think. > > I think it’s fine. Just update the comment there and mention that it > can serve another purpose as well. > > [...] >>> Then the oldest generation will maintain the same folio order as the >>> inactive list. >>> >> Thanks for the suggestion. Traversing head to tail does fix the inversion, but >> we need to distinguish active from inactive during iteration, because they are >> inserted differently: list_add_tail() when reclaiming, and list_add() otherwise. >> That said, the reclaim argument usage still feels off to me—I'd like to hear if >> others have a better idea before we proceed with further changes. > > We can change reclaim to a tristate integer, or simply make the > following change and add a comment explaining why? > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 9e52f49114e7..5e624d0316bc 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -5403,7 +5403,8 @@ static bool fill_evictable(struct lruvec *lruvec) > > while (!list_empty(head)) { > bool success; > - struct folio *folio = lru_to_folio(head); > + struct folio *folio = active ? lru_to_folio(head) : > + list_entry((head)->next, struct folio, lru); > I've sent a new patch following this approach. Link: https://lore.kernel.org/linux-mm/20260820072641.253591-1-ridong.chen@linux.dev/T/#u > Or you could even move the entire inactive list to the oldest gen > instead of moving the folios one by one. Then you can avoid dealing > with the reclaim argument entirely. > However, since MGLRU distinguishes zones, we would have to move the folios one by one. So I've dropped this approach. -- Best regards Ridong