From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 4CDD1282F13 for ; Tue, 25 Aug 2026 00:59:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787619603; cv=none; b=msouzC8jjodlblZdksai/J6fM4WZTk85ex6ZCfzZe1aDWleZ5MFsC1C74ksg2wMnmMSElOw4G7yA9fG+c4RumdHQjSz/1qDb2Ght+Lc/QbTmlGjNHOJtZ/OtsKQ86BCzLWdpeya7JyRvvM4UhMXDv4OhTDy8JttMG1FKSBsJtH4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787619603; c=relaxed/simple; bh=2pgbypz8HsTTihKRr3WhHU9pZyDHtrISv5wjwHnJ634=; h=Message-ID:Date:MIME-Version:CC:Subject:To:References:From: In-Reply-To:Content-Type; b=cQjO7dQ2MGBkI4Ztwuf8EKlCjiJlkbt4IsT3HGlc5uvI06F5ZXCeTwtI6+k/mdiK5WbaHnSnySjXcYHKtkKrfv2cO2RCLmoTj1oh0Tz3KygsweY0jG2U1Ck+q2MydoJrUm3FvaGp39Hn3WbviR9qZGpGQMNZKJ7LbY3AnImyVKU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Y+Nj0QVf; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Y+Nj0QVf" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=f4qPy68Jjy02vLHv5nPbtQT7BMvyEVJ0wPWW7uigLt8=; b=Y+Nj0QVfpOGaQXqQ3Fi4T5/hmi+uBcDuV+Q9bPxhK2TEOTncZcMm2od73usG2VFQePJJfeocO 4mVEaN/qqGNPFkjayljH0TsCNIRqvWnkezEaM9skJmnrm09dE+WyiznqGBguT0JNqwWbrWBOEmU 7vy/6A2RAkh63w9BGgf4jEc= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4hTTgY1gFdzRhRG; Tue, 25 Aug 2026 08:49:13 +0800 (CST) Received: from kwepemj100016.china.huawei.com (unknown [7.202.194.10]) by mail.maildlp.com (Postfix) with ESMTPS id 1BBE24057F; Tue, 25 Aug 2026 08:59:56 +0800 (CST) Received: from [10.174.177.15] (10.174.177.15) by kwepemj100016.china.huawei.com (7.202.194.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 25 Aug 2026 08:59:55 +0800 Message-ID: Date: Tue, 25 Aug 2026 08:59:54 +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 CC: , , , , , , , , , , , , Subject: Re: [PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning To: References: <20260811070849.1332165-1-mawupeng1@huawei.com> <20260811184241.e423b81c8a50d5f212af1c3b@linux-foundation.org> From: mawupeng In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemj100016.china.huawei.com (7.202.194.10) Hi, maintainers Kindly ping. On 周三 2026-8-12 10:29, mawupeng wrote: > > > On 周三 2026-8-12 09:42, Andrew Morton wrote: >> On Tue, 11 Aug 2026 15:08:47 +0800 Wupeng Ma wrote: >> >>> shrink_lruvec() drives reclaim in SWAP_CLUSTER_MAX (32) chunks, but >>> isolate_lru_folios() may scan far more than that per call on a single >>> LRU. The excess is never charged back, so shrink_lruvec() keeps >>> rescanning the same folios round after round. When reclaim targets a >>> lower zone, the same scanner also keeps walking zone-ineligible folios >>> that can never satisfy the allocation, inflating nr_reclaimed into a >>> false progress that delays the OOM. >>> >>> This series fixes both: >>> >>> [1/2] Charge the isolate overshoot against the scan quota so the >>> next round skips already-scanned folios. >>> [2/2] Stop scanning once too many zone-ineligible folios have been >>> skipped, instead of force-isolating them. >> >> This all sounds fairly bad. Is there some report? Real-world test >> results? Laboratory test results? Something to help us understand the >> impact of the issues and the situations in which they occur. >> > > Sorry — this background belongs in the cover letter and I left it > out. Adding it here. > > ## Situation > > We observed slow, unexpected OOM behavior during extreme stress testing, > and while digging into the reclaim code during that analysis we spotted > these latent risks in isolate_lru_folios() — the overshoot never > being charged back, and the force-isolate path on lower-zone reclaim. > The concerns below are the ones surfaced from reading the code, then > confirmed by constructing the situation deliberately. > > The problem only appears when reclaim targets a lower zone while the > LRU holds folios from a higher zone: > > - reclaim_idx points at DMA32/DMA (the triggering allocation asked > for a lower zone, e.g. __GFP_DMA32), and > - the LRU holds folios from a higher zone (Normal/Movable). > > Normal userspace allocations go to the highest zone, so reclaim_idx > never points below it and the zone-skip branch is never taken. It > needs a real lower-zone allocator to drain that zone below watermark; > that is also why it went unnoticed upstream — the 1c7b17cf hard-lockup > fix that introduced the force-isolate path was found only on a ~1 TB > box running DMA32 module allocations. > > ## Impact > > Reproduced on x86 QEMU, 7.2-rc6, with a kernel module doing > __GFP_DMA32 allocations to drain DMA32 below watermark (LRU folios > sit in Movable): > > - A single isolate_lru_folios() call scanned 32794 pages and took > 25 (32769 skipped): 99.9% wasted on ineligible folios. > - Across one run, isolate was called 339 times, 140-165 of which > isolated nothing (taken=0, pure empty scans). > - shrink_lruvec() charges only the 32-page quota per round and > never refunds the overshoot, so the same skipped folios are > rescanned round after round. vmstat on a memcg OOM path: > Δpgscan_direct / Δpgsteal_direct = 2836624 / 112719 = 25.2x > (isolate -> shrink_folio_list returns the folio -> isolate again). > > Once max_nr_skipped hits SWAP_CLUSTER_MAX_SKIPPED, the current code > force-isolates the remaining ineligible folios. On the inactive LRU > they reach shrink_folio_list() and get reclaimed though they can > never satisfy the allocation, inflating nr_reclaimed and resetting > no_progress_loops in should_reclaim_retry(), delaying the OOM. > > ## A/B results (same .config, md5-identical) > > | metric | baseline | patched | note | > |-------------------------|------------|---------|------| > | empty scans (taken=0) | 140-165 | 0 | stable across runs | > | isolate calls | 339 | 7 | 48x fewer | > | total pages scanned | 343711 | 3140 | 109x fewer | > | single-call max scan | 32794 | 3104 | | > > Empty-scan 0 is the stable evidence (holds every run). The > Δpgscan/Δpgsteal ratio is volatile (baseline 56-26675x, patched > 65-1324x, ranges overlap) and is not relied on alone. > > ## Caveats and reproduction > > - Triggering needs a lower-zone-pressured box. To confirm the code > analysis, the situation was constructed on a small x86 QEMU VM > (1500M, CONFIG_LRU_GEN=n) with kernel cmdline > `movable_zone=DMA32 kernelcore=256M` (DMA32 small, Normal empty, > Movable large), then a kernel module doing > `alloc_page(GFP_DMA32)` drains DMA32 below watermark. LRU folios > sit in Movable and are zone-skipped while reclaiming for DMA32. > Observed via the `mm_vmscan_lru_isolate` tracepoint and > /proc/vmstat (pgscan_direct, pgsteal_direct). > >> Thanks. >