From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (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 2DFD23B7776 for ; Tue, 24 Mar 2026 07:22:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774336978; cv=none; b=ZKeNl4CnrMckNbCRmN+xsy/n3P/6CccLkBgaZI0JgxhMKj0LIIy+PKcQ2+fCK3ms+ouyp+CJhU19XFu1oYFN/U777gIEzjXO0869TlIQJKp/Flc5fSowMLE13MD0KzqNabCvkEq25j6ZtQimrZqi5KUAxh4mCzGsG8MKQd6JZwE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774336978; c=relaxed/simple; bh=ZdP+8910gxjDjl1Ykev4iAhJu1c1F9yjcTKk2XbZun4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZVW/H7zWujJqhIoqnbAfYsWUElav1BHQWpuDbVh2YkqKCBBoCy6Hh1QA3Hc6Wu4dW11uN9+SOFejve7WcFMDZsr4sVAoFlat91IPqCtUnIwpe2Av8zpllnhNcA+T+8O8JZJtL82xw264F8BdfKY84wlFoClMPGVOAwJDmMJBcWI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.177]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4fg1h04Y9mzKHMV6 for ; Tue, 24 Mar 2026 15:22:08 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 661E44058D for ; Tue, 24 Mar 2026 15:22:45 +0800 (CST) Received: from [10.67.111.176] (unknown [10.67.111.176]) by APP4 (Coremail) with SMTP id gCh0CgAX8UvDO8JpUawyCA--.57253S2; Tue, 24 Mar 2026 15:22:45 +0800 (CST) Message-ID: <0427249d-c6c7-477a-aeff-e007198fcf45@huaweicloud.com> Date: Tue, 24 Mar 2026 15:22: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 4/8] mm/mglru: scan and count the exact number of folios To: Kairui Song , Axel Rasmussen Cc: linux-mm@kvack.org, Andrew Morton , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , 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-4-2c46f9eb0508@tencent.com> Content-Language: en-US From: Chen Ridong In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:gCh0CgAX8UvDO8JpUawyCA--.57253S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtrW7Jr1xXr4DGF43Kr17KFg_yoW7Ww4fpF ZxKay2yFW8XrWagryvqr4Fkr1akrZ8tryxXFyxAw1ayFnIqFyfG3W3Kw1jkFWUur48CF10 v3W7KF47u3WjqFDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv0b4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS 14v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWr XwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IU0 s2-5UUUUU== X-CM-SenderInfo: hfkh02xlgr0w46kxt4xhlfz01xgou0bp/ On 2026/3/23 0:20, Kairui Song wrote: > On Sat, Mar 21, 2026 at 4:59 AM Axel Rasmussen wrote: >> >> On Tue, Mar 17, 2026 at 12:11 PM Kairui Song via B4 Relay >> wrote: >>> >>> From: Kairui Song >>> >>> Make the scan helpers return the exact number of folios being scanned >>> or isolated. This should make the scan more accurate and easier to >>> follow. >>> >>> Now there is no more need for special handling when there is no >>> progress made. The old livelock prevention `(return isolated || >>> !remaining ? scanned : 0)` is replaced by the natural scan budget >>> exhaustion in try_to_shrink_lruvec, and sort_folio moves ineligible >>> folios to newer generations. >>> >>> Signed-off-by: Kairui Song >>> --- >>> mm/vmscan.c | 27 +++++++++++---------------- >>> 1 file changed, 11 insertions(+), 16 deletions(-) >>> >>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>> index ed5b5f8dd3c7..4f4548ff3a17 100644 >>> --- a/mm/vmscan.c >>> +++ b/mm/vmscan.c >>> @@ -4680,7 +4680,7 @@ static bool isolate_folio(struct lruvec *lruvec, struct folio *folio, struct sca >>> >>> static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec, >>> struct scan_control *sc, int type, int tier, >>> - struct list_head *list) >>> + struct list_head *list, int *isolatedp) >>> { >>> int i; >>> int gen; >>> @@ -4750,11 +4750,9 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec, >>> type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON); >>> if (type == LRU_GEN_FILE) >>> sc->nr.file_taken += isolated; >>> - /* >>> - * There might not be eligible folios due to reclaim_idx. Check the >>> - * remaining to prevent livelock if it's not making progress. >>> - */ >>> - return isolated || !remaining ? scanned : 0; >>> + >>> + *isolatedp = isolated; >>> + return scanned; >>> } >>> >>> static int get_tier_idx(struct lruvec *lruvec, int type) >>> @@ -4819,23 +4817,24 @@ static int isolate_folios(unsigned long nr_to_scan, struct lruvec *lruvec, >>> int *type_scanned, struct list_head *list) >>> { >>> int i; >>> + int scanned = 0; >>> + int isolated = 0; >>> int type = get_type_to_scan(lruvec, swappiness); >>> >>> for_each_evictable_type(i, swappiness) { >>> - int scanned; >>> int tier = get_tier_idx(lruvec, type); >>> >>> *type_scanned = type; >> >> I think this is problematic, now `isolate_folios` can scan a nonzero >> amount of > 1 type of memory. Then the caller (`evict_folios`) calls >> `trace_mm_vmscan_lru_shrink_inactive` with the total scanned amount, >> with only the last type we scanned (misattributing part of the scan, >> potentially). Not a "functional" issue, but it could mean confusing >> data for anyone watching the tracepoint. > > Thanks! Nice catch, I'll introduce another variable for the tracepoint > then it should be fine. > >> >> >>> >>> - scanned = scan_folios(nr_to_scan, lruvec, sc, >>> - type, tier, list); >>> - if (scanned) >>> + scanned += scan_folios(nr_to_scan, lruvec, sc, >>> + type, tier, list, &isolated); >>> + if (isolated) >>> return scanned; >>> >>> type = !type; >>> } >>> >>> - return 0; >>> + return scanned; >>> } >>> >>> static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, >>> @@ -4852,7 +4851,6 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, >>> struct reclaim_stat stat; >>> struct lru_gen_mm_walk *walk; >>> bool skip_retry = false; >>> - struct lru_gen_folio *lrugen = &lruvec->lrugen; >>> struct mem_cgroup *memcg = lruvec_memcg(lruvec); >>> struct pglist_data *pgdat = lruvec_pgdat(lruvec); >>> >>> @@ -4860,10 +4858,7 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, >>> >>> scanned = isolate_folios(nr_to_scan, lruvec, sc, swappiness, &type, &list); >>> >>> - scanned += try_to_inc_min_seq(lruvec, swappiness); >>> - >>> - if (evictable_min_seq(lrugen->min_seq, swappiness) + MIN_NR_GENS > lrugen->max_seq) >>> - scanned = 0; >>> + try_to_inc_min_seq(lruvec, swappiness); >> >> IIUC, this change is what introduces the issue patch 6 is trying to >> resolve. Is it worth squashing patch 6 in to this one, so we don't >> have this non-ideal intermediate state? > > Well it's not, patch 6 is fixing an existing problem, see the cover > letter about the OOM issue. > > This part of changing is just cleanup the loop code. It looks really > strange to me that increasing min_seq is considered as scanning one > folio. Aborting the scan if there is only 2 gen kind of make sense but > this doesn't seems the right place. These strange parts to avoid > livelock can be dropped since we have an exact count of folios being > scanned now. I'll add more words in the commit message. This change confused me too. IIUC, this change looks conceptually tied to patch 3. The following change means that evict_folios should not be invoked if aging is needed. So the judge can be dropped there, right? ``` static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) { ... + if (should_run_aging(lruvec, max_seq, sc, swappiness)) { + if (try_to_inc_max_seq(lruvec, max_seq, swappiness, false)) + need_rotate = true; + break; + } ``` -- Best regards, Ridong