From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-128.mta1.migadu.com [95.215.58.128]) (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 032113546F2 for ; Mon, 24 Aug 2026 03:05:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.128 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787540722; cv=none; b=Dc/WbwxRhfIPujGvnFpWf6nVstZLF1JINSTSa1hiLL2xs1LHsXTeh1dkJUhzXkyfr63UwMX7aq/2X32OowBzX4bUuoYIn44K3z9WVCKlRc34jj88oAwdgpSFcAzaB32Zz40/oXTu4s/iG5yGqcfM/ts0/FSiJJO1HkI2b4WqWYQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787540722; c=relaxed/simple; bh=TqxJYfxm291IpdzCBiyyGro/c+1ngMIo68kvFi7jpgw=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=MElrB1IPz8SWmuKBHjdXZrqST09DMpVGobvNBpUQQPDTs5KSuiLzOCKsFdoJLrnUW7xqUEk/oKwkbc8vC616ZLyN/oFdK+AfV7I8rIBDeQqhJ/LgPd6Ab+jBieLnWtezY9Pq/AdQYrDMCbMRdFAR0uVM5scsj7Od5R6FHHfWNYY= 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=sO9BQ/fq; arc=none smtp.client-ip=95.215.58.128 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="sO9BQ/fq" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=TqxJYfxm291IpdzCBiyyGro/c+1ngMIo68kvFi7jpgw=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787540718; v=1; x=1788145518; b=sO9BQ/fqXTkAmaWH0m41sN8IgWKMQ8Ncx5UzT2kiVFPJpbi4mwuVsbOk4d9NrIU9PUU3NFby DfvOjNHkjcaw/GOjMxjXf4JZy29sUkR59iTGdZGT1cL5m2gIU2tpoFK2i7ggZZZCQrx8i8FEeYi qz///EzoKDUH39Jughydfqss= X-Envelope-To: linux-kernel@vger.kernel.org Received: from webmail.migadu.com (2001:41d0:303:fc7a::) by smtp.migadu.com with ESMTPS id 900464cc304e1d33; Mon, 24 Aug 2026 03:05:17 +0000 X-Mizu-Trace-ID: 900464cc304e1d33 X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Mon, 24 Aug 2026 03:05:13 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Hui Zhu" Message-ID: <90ff25cba63491e21a29e92b99f884bffde4eba2@linux.dev> TLS-Required: No Subject: Re: [PATCH mm-unstable v4 0/2] mm/vmscan: fix NR_ISOLATED accounting and throttling for MGLRU To: "Kairui Song" Cc: "Andrew Morton" , "Qi Zheng" , "Shakeel Butt" , "Barry Song" , "Axel Rasmussen" , "Yuanchu Xie" , "Wei Xu" , "Johannes Weiner" , "David Hildenbrand" , "Michal Hocko" , "Lorenzo Stoakes" , "Baolin Wang" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Hui Zhu" In-Reply-To: References: >=20 >=20On Thu, Aug 20, 2026 at 10:49 AM Hui Zhu wrote: >=20 >=20>=20 >=20> From: Hui Zhu > >=20 >=20Hello, thanks for the update! >=20 >=20>=20 >=20> The legacy reclaim path updates the NR_ISOLATED_ANON/FILE node > > counters around isolation and throttles direct reclaimers via > > too_many_isolated() when isolated folios pile up. The MGLRU eviction > > path does neither: evict_folios() isolates folios without touching > > the counters and never consults too_many_isolated(). > >=20 >=20> Patch 1 updates NR_ISOLATED_ANON/FILE around isolation in > > evict_folios(), reusing the existing nr_isolated. Without this the > > counters stay at zero while MGLRU reclaim is active, so compaction's > > too_many_isolated() cannot see the pages MGLRU has isolated. > >=20 >=20> Patch 2 adds throttle_evictable_types() and calls it from > > evict_folios(), before the lruvec lock is taken since throttling > > sleeps, leaving the legacy path untouched. The MGLRU check differs > > from the legacy per-list one in shrink_inactive_list() because > > isolate_folios() picks the type to scan from the refault feedback > > and may fall back to the other one: it computes the set of evictable > > types that are not over-isolated and only sleeps when all of them > > are, waiting once for concurrent reclaimers exactly like the legacy > > path. The mask of the remaining types is passed to isolate_folios(), > > which restricts both its initial choice and its fallback to it, so > > isolation never lands on an over-isolated type and a type that is > > merely over-isolated never blocks the reclaim of the other one. > > This way the MGLRU eviction path backs off when isolated folios pile > > up instead of thrashing the shrinking LRU lists - the scenario the > > too_many_isolated() check exists for. A dying task fakes reclaim > > progress exactly like the legacy path so it exits reclaim quickly. > >=20 >=20Hmm, could too_many_isolated gets over aggressive or over passive, > since the inactive number of MGLRU is just a compatiblity shim and > does not have the same meaning of classical LRU? Especially when you > run out of swap space or hit a memcg's swap limit, the anon inactive > number becomes a jumpy random number. Proactive aging also makes the > inactive number become huge for MGLRU. I still think even a "/ > MIN_NR_GENS" is better than using inactive value, MGLRU used to use > that as the aging trigger like this: >=20 >=20if (young * MIN_NR_GENS > total) > return true; > if (old * (MIN_NR_GENS + 2) < total) > return true; >=20 Agreed.=20The next version drops the inactive-based threshold and instead compares the isolated count against the total evictable pages of the type divided by MIN_NR_GENS, and makes the check per lruvec, where the MGLRU isolation happens. > >=20 >=20> Testing > > =3D=3D=3D=3D=3D=3D=3D > >=20 >=20> Test on 8G RAM qemu. > > The reproducer confines stress-ng workers in a 192M memcg and swaps > > through dm-delay (300ms write latency) so pageout is slow and isolat= ed > > folios pile up; the workload is intentionally extreme. nr_isolated_* > > is sampled every 50ms against the per-type too_many_isolated > > threshold (inactive/8), and throttle events are counted via the > > mm_vmscan_throttled tracepoint. > > The test scripts and test log are in [1]. > >=20 >=20> Test 1, reclaim throttling, parallel direct reclaim in the memcg: > >=20 >=20> before after > > throttle events (ISOLATED) 0 0 > > - from kswapd 0 0 > > nr_isolated_anon peak 0 3166 > > nr_isolated_file peak 0 174 > > - samples above the > > too_many_isolated threshold 0/1088 89/1077 > > pgscan_direct 1540044096 858332151 > > pswpout 6299497 725819 > >=20 >=20The throttling avoids premature OOM and over scan when there are too > many reclaimers, it is not for IO balancing. Because writeback folios > are not isolated, they are putback to LRU waiting to be rotated, not > isolated. So reclaimers never wait on the device however slow the > device is (except cgroup V1 have some special quirks I think we should > ignore), it's mostly CPU bound. I think the mechanism might be a bit > outdated, even for classical LRU. >=20 >=20The result just shows that swap became less aggressive when under > pressure, which is somewhat counter-intuitive. Overly aggressive > throttling will unnecessarily slows performance if anon pages are > actually cold or should be evicted. These results reflect a reclaim > behavior change, not a performance improvement. And I think we > shouldn't rely on throttling for balancing, those are two different > things. Heat or I/O cost-based methods are better. Right. This script is only meant to show that the isolation accounting and the throttling kick in; it was not intended as a performance evaluation. As you pointed out, it also sampled the old node-level inactive-based threshold, which no longer matches the new check. Will provide a new test aimed at the premature OOM / overscanning scenario. >=20 >=20For example the test you posted, it just stress-ng which only spawns > anon memory IIUC, so when you reclaim file, your code segments got > reclaimed and hence the process stall and has to wait for code > segments IO, which I think it will only slowdown the actual > performance? > Yes, will fix that in the new test as well. Best, Hui