From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 69D3812E1E9 for ; Thu, 26 Mar 2026 07:31:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774510311; cv=none; b=jV5ej09FJFDRR3hf5sBFfzLDvJGjAmwl7fsEpftzhayQWj75IRhXzjkPgdw7o83rExHn2IOXUTE5ryQ7G+SLuxKU+K2nlRDAyEDsmpmkkEnL77UP+yxaDYDvHGyvKVd1I9KYQIk2mURD1J+5qlaD1oHHjikXGbJFljDwWxzOu6U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774510311; c=relaxed/simple; bh=dxRmAAQggnbnoGAAXs4thB4IEKvYcVHKBOvPQeqBe9g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cMzPNSJ53YjyEcLnnJCxtn8Z/Bav1Q8ekhoMuSGVE1BDpkCvgkj1obSvlNbwYp2onL569gLT9U3DGFUU1BGQ1oHxSUs0h8sR0QCdUnjA+o8RMSnpvevocrwO/m/PA3xXRfCEH1GAXZ7UzGCmCXfBkwIyIyfxAYe8bFDsy9rgcKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=xClEX6AI; arc=none smtp.client-ip=115.124.30.113 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="xClEX6AI" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774510306; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=SlrYYEPTUwcgSKk4qDq+lYdB7FJlgZsayA6Icmo5ezM=; b=xClEX6AIZg72Q/qH1Tph13X1lHg6vq7UukBYz1LijFfOP3Btz7cguJCu3e5l6pJ09rwjU0iAHM6Ln2X4R3lEgsANaY4pKGYyxPb5oFqF0CO757eRF6MWBjLhT5kG63iHUx9b2gpnaAHnK7hhKHJ22kgO/QPl1vt74Xkd+Tyj0RA= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=24;SR=0;TI=SMTPD_---0X.kcP21_1774510304; Received: from 30.74.144.123(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.kcP21_1774510304 cluster:ay36) by smtp.aliyun-inc.com; Thu, 26 Mar 2026 15:31:45 +0800 Message-ID: Date: Thu, 26 Mar 2026 15:31:43 +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 3/8] mm/mglru: restructure the reclaim loop To: kasong@tencent.com, linux-mm@kvack.org Cc: Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Chen Ridong , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org References: <20260318-mglru-reclaim-v1-0-2c46f9eb0508@tencent.com> <20260318-mglru-reclaim-v1-3-2c46f9eb0508@tencent.com> From: Baolin Wang In-Reply-To: <20260318-mglru-reclaim-v1-3-2c46f9eb0508@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/18/26 3:08 AM, Kairui Song via B4 Relay wrote: > From: Kairui Song > > The current loop will calculate the scan number on each iteration. The > number of folios to scan is based on the LRU length, with some unclear > behaviors, eg, it only shifts the scan number by reclaim priority at the > default priority, and it couples the number calculation with aging and > rotation. > > Adjust, simplify it, and decouple aging and rotation. Just calculate the > scan number for once at the beginning of the reclaim, always respect the > reclaim priority, and make the aging and rotation more explicit. > > This slightly changes how offline memcg aging works: previously, offline > memcg wouldn't be aged unless it didn't have any evictable folios. Now, > we might age it if it has only 3 generations and the reclaim priority is > less than DEF_PRIORITY, which should be fine. On one hand, offline memcg > might still hold long-term folios, and in fact, a long-existing offline > memcg must be pinned by some long-term folios like shmem. These folios > might be used by other memcg, so aging them as ordinary memcg doesn't > seem wrong. And besides, aging enables further reclaim of an offlined > memcg, which will certainly happen if we keep shrinking it. And offline > memcg might soon be no longer an issue once reparenting is all ready. > > Overall, the memcg LRU rotation, as described in mmzone.h, > remains the same. > > Signed-off-by: Kairui Song > --- Overall, I really like the code cleanup here, and it makes the code much more readable. Thanks for your work. However, one concern is that you've mixed some functional changes (such as the offline memcg aging and shifting the scan number by reclaim priority) into these cleanups. This makes the commit difficult to review, though I think the functional changes make sense to me. Can we split this up? That means you can send the cleanups as a separate patch first, followed by the functional changes in the following patches with an explanation of their impact. Then reviewers can focus on discussing the functional changes.