From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (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 A2749288AD for ; Tue, 18 Aug 2026 03:36:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787024183; cv=none; b=GEQRuFW7iKdLl76+AEzbrxxaQcN5fJOvXQyYc9vAPDLTxeRt4DaqBcK8e88SlekBsWY6ObQMKtL+YQH3huo0umZUggux0HoAKMVCmuXFlYdX4ct8bWPT+HfKIzsoaM+HnVFXSFYB10iRYoNlsYgVTbmDKvIgN406YKMUZb7r4L4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787024183; c=relaxed/simple; bh=jQFazjJOsA0FJDIqohmCIRNzracpBVJQWHm+GoTsBsA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SzZKh9ZIlM2aL8D3b8EHcksOwYAqSNtNS7GdheqCgKdz+WOedB8CE9d7I+n/LAZU9dJlCQJELT6iwaGEisVWJ7X+xsxbwK5YC9hTeEPwbUbggHg624VLVprLK8h2SbiR5RWGGj5lKLRoglWlsoIdH1AYrztb0hp03LWBXy8d5OM= 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=mwt/+vdK; arc=none smtp.client-ip=115.124.30.119 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="mwt/+vdK" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1787024175; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=pLRJ4oNNFpYWGdiEIZ6Tl4aYLJPaTNBMq+3LGFYpe7Y=; b=mwt/+vdK51+Fg/ukA1fa7KvQj9uITU+MpXi9pGGyzhLqbZMGyyMh046LnqMV3PLUrQpM2djlQKG8Dz1aniPt9ej388ua9ElG+VZqUghjr1w2tfJTxh4hTn12WGV/M2npYupcBKL3LYoi7kRFbz478NuC82tyZg6SQwureQP8xmU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R271e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_---0X9BvX3n_1787024174; Received: from 30.74.144.114(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X9BvX3n_1787024174 cluster:ay36) by smtp.aliyun-inc.com; Tue, 18 Aug 2026 11:36:15 +0800 Message-ID: Date: Tue, 18 Aug 2026 11:36:14 +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 mm-unstable v2 2/2] mm/vmscan: apply too_many_isolated() throttling to MGLRU eviction To: Hui Zhu , Andrew Morton , Kairui Song , Qi Zheng , Shakeel Butt , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Hui Zhu References: <858e2e0ae536bbe185267472d3c84a5684937131.1786950138.git.zhuhui@kylinos.cn> From: Baolin Wang In-Reply-To: <858e2e0ae536bbe185267472d3c84a5684937131.1786950138.git.zhuhui@kylinos.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 8/17/26 3:11 PM, Hui Zhu wrote: > From: Hui Zhu > > The legacy path throttles direct reclaim in shrink_inactive_list() > when too many isolated folios pile up, but MGLRU's evict_folios() > isolates folios without this check, which can lead to unnecessary > swapping, thrashing and OOM. > > With the NR_ISOLATED counters now updated in evict_folios(), extract > the throttling loop from shrink_inactive_list() into > throttle_isolated() and reuse it in evict_folios(). The type to > isolate is predicted with get_type_to_scan() since it is unknown > until isolation. > > If a fatal signal is pending, fake reclaim progress the same way the > legacy path does, so the dying task exits reclaim quickly instead of > being held in the throttle. > > Signed-off-by: Hui Zhu > --- > mm/vmscan.c | 67 ++++++++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 56 insertions(+), 11 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index fdc45d7d8fba..886a53f563ab 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1819,7 +1819,7 @@ bool folio_isolate_lru(struct folio *folio) > * the LRU list will go small and be scanned faster than necessary, leading to > * unnecessary swapping, thrashing and OOM. > */ > -static bool too_many_isolated(struct pglist_data *pgdat, int file, > +static bool too_many_isolated(struct pglist_data *pgdat, bool file, > struct scan_control *sc) > { > unsigned long inactive, isolated; > @@ -1856,6 +1856,37 @@ static bool too_many_isolated(struct pglist_data *pgdat, int file, > return too_many; > } > > +/* > + * Throttle reclaim if too many isolated folios are piling up. If this makes > + * no progress, the caller is probably looping on unevictable folios, so give > + * up. Returns false to tell the caller to stop reclaiming, and sets @fatal > + * if the task received a fatal signal while waiting, so that the caller can > + * bail out faster. > + */ > +static bool throttle_isolated(struct pglist_data *pgdat, bool file, > + struct scan_control *sc, bool *fatal) > +{ > + bool stalled = false; > + > + *fatal = false; > + while (unlikely(too_many_isolated(pgdat, file, sc))) { > + if (stalled) > + return false; > + > + /* wait a bit for the reclaimer. */ > + stalled = true; > + reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED); > + > + /* We are about to die and free our memory. Return now. */ > + if (fatal_signal_pending(current)) { > + *fatal = true; > + return false; > + } > + } > + > + return true; Returning ‘true’ or 'false' looks confusing to me, maybe use a readable variable 'is_throttled'? > +} > + > /* > * move_folios_to_lru() moves folios from private @list to appropriate LRU list. > * > @@ -1992,19 +2023,14 @@ static unsigned long shrink_inactive_list(unsigned long nr_to_scan, > bool file = is_file_lru(lru); > enum node_stat_item item; > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > - bool stalled = false; > - > - while (unlikely(too_many_isolated(pgdat, file, sc))) { > - if (stalled) > - return 0; > - > - /* wait a bit for the reclaimer. */ > - stalled = true; > - reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED); > + bool fatal; > > + if (!throttle_isolated(pgdat, file, sc, &fatal)) { > /* We are about to die and free our memory. Return now. */ > - if (fatal_signal_pending(current)) > + if (fatal) > return SWAP_CLUSTER_MAX; > + > + return 0; > } > > lru_add_drain(); > @@ -4883,6 +4909,25 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, > bool skip_retry = false; > struct mem_cgroup *memcg = lruvec_memcg(lruvec); > struct pglist_data *pgdat = lruvec_pgdat(lruvec); > + bool fatal; > + > + /* > + * The type to isolate is unknown until isolation, so predict it for > + * the throttling check. isolate_folios() may still fall back to the > + * other type, which is fine for this heuristic. > + */ > + type = get_type_to_scan(lruvec, swappiness); Perhaps we could use 'for_each_evictable_type(i, swappiness)' to check each type's isolation? > + if (!throttle_isolated(pgdat, type, sc, &fatal)) { > + /* > + * We are about to die and free our memory. Like the legacy > + * path, pretend some pages were reclaimed so reclaim unwinds > + * quickly instead of looping back into the throttle. > + */ > + if (fatal) > + sc->nr_reclaimed += SWAP_CLUSTER_MAX; > + > + return 0; > + } > > lruvec_lock_irq(lruvec); >