From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (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 D92A9314B77 for ; Wed, 15 Apr 2026 03:16:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776222993; cv=none; b=i4LcR4TgXFuXh9TjZR+mBx3UmNPaAcn/KhQeY2w620vMTyCH8ifiWBffcbMztTvlLa5AuX8YSrQljBUsX/jjjllBYxtn73caEPnINoY5QnRV4q44ZF4KuE5v5HaEgTUBsOzEWAnT0YdPUj0LcAg6SP8hUnVgW8H0Ud9TPde3ohM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776222993; c=relaxed/simple; bh=iVHyZErvxeYV20Zkc910q9Lmm8H8mj9xbCa8iUDgDEY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fFuagrcdV/Jo3C9882vyv3eHbzV9TEg4jhlUL67qvtxz8vFEZdE6TTF0leogZtbt1Bz29877wdEGO4n+chkaBTNWmELL1lIw56dPdCs+MNTyh8wsIfk+2AQkxGAhQqbZmVXyKxHViOW7zmo9AXaWwDjbLMGnNhbbD8W47RLl/dQ= 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=a+MMtCWQ; arc=none smtp.client-ip=115.124.30.118 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="a+MMtCWQ" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776222982; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=INOKKU/DUYfCs/lHfTk6eEwVUS5M/lRl2T8/ng8E9CM=; b=a+MMtCWQROW0M/IQlzhHuQlHwW6YHaNlPcYCp5o+m9m6j9JWT+i3A9QOWjk4XyW7YPE+ws4jE6EBX6Hy7s9LMkRbtpUA+nm5BPUeZ44I522zKjUtmkfqN8wGEQh4A+j05JzmdKQYN8vAsIIIDVbjdvYJF0apw1CsDkAhgDOdr3E= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R261e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037033178;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=25;SR=0;TI=SMTPD_---0X138wtU_1776222980; Received: from 30.74.144.121(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X138wtU_1776222980 cluster:ay36) by smtp.aliyun-inc.com; Wed, 15 Apr 2026 11:16:21 +0800 Message-ID: Date: Wed, 15 Apr 2026 11:16:19 +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 v5 05/14] mm/mglru: scan and count the exact number of folios 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, Qi Zheng References: <20260413-mglru-reclaim-v5-0-8eaeacbddc44@tencent.com> <20260413-mglru-reclaim-v5-5-8eaeacbddc44@tencent.com> From: Baolin Wang In-Reply-To: <20260413-mglru-reclaim-v5-5-8eaeacbddc44@tencent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/13/26 12:48 AM, Kairui Song via B4 Relay wrote: > From: Kairui Song > > Make the scan helpers return the exact number of folios being scanned > or isolated. Since the reclaim loop now has a natural scan budget that > controls the scan progress, returning the scan number and consume the > budget should make the scan more accurate and easier to follow. > > The number of scanned folios for each iteration is always positive and > larger than 0, unless the reclaim must stop for a forced aging, so > there is no more need for any special handling when there is no > progress made: > > - `return isolated || !remaining ? scanned : 0` in scan_folios: both > the function and the call now just return the exact scan count, > combined with the scan budget introduced in the previous commit to > avoid livelock or under scan. > > - `scanned += try_to_inc_min_seq` in evict_folios: adding a bool as a > scan count was kind of confusing and no longer needed to, as scan > number should never be zero as long as there are still evictable > gens. We may encounter a empty old gen that return 0 scan count, > to avoid that, do a try_to_inc_min_seq before isolation which > have slight to none overhead in most cases. > > - `evictable_min_seq + MIN_NR_GENS > max_seq` guard in evict_folios: > the per-type get_nr_gens == MIN_NR_GENS check in scan_folios > naturally returns 0 when only two gens remain and breaks the loop. > > Also change try_to_inc_min_seq to return void, as its return value is > no longer used by any caller. Move the call before isolate_folios so > that any empty gens created by external folio freeing are flushed, and > add another call after isolate_folios to also flush empty gens that > isolation itself may create. As I mentioned earlier, the try_to_inc_min_seq() changes here indeed fall outside the scope of "Make the scan helpers return the exact number of folios being scanned or isolated." However, the changes still make sense to me. Anyway, I don't have a strong opinion on this (there's no need for another iteration), so: Reviewed-by: Baolin Wang