From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793826763; b=SEFzCBXi67GM5mWGSINTARBSebBfo1H6X6BXSfEhwq2cEFe5wLO7EHKoiFuy5EFFQUjg 58Ldz3vAUyTSq6own7qhLgWI5TnWKW6u00H6YdOylr1Gu99Qf0qil7U6TTp1utWOtDG9C KjNFzbHMCohpyiwSjlX51KFtrWC5HYiZ+DJWCA79P1K54TTVCd5I+9R7ejeHiikXMIDjK 0PLFAP1nNkTyyPlgLkCc+PNqqknW6ic4sEuJpaSCkA5zNwHs18eI/1NsBeYaV8xpSrN71 y0hcDJaLWtLRa6cO31OBa1OZuq6CnjZjmrSMi39TQGYD3qOAnf9dDVw90HIMJGoVuyA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793826763; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=DvemVXISlO2P3Tj6vrQMxZUWeZt/QLe5Wd8LlKCSvVw=; b=EGpgjTeGocFjMsBMczTJUC8+8lhUT4CD2cZfqrHLvDiY91sYFyRXLD9KxaYki8O9Kcrw mIwP8Cq8owlz0do1vEYXV729YjJvQtwBv7i9OGpAD34e6j36WQZL3lGfIUfAx3iE2UkDP tVVDtnP5vN+18c1bOcQ8Lo2uqOfQDFNOdsXENZ8bLBgqqTetACJB2W4xmchwSQj8LDpb+ vBJ4Nfq91EO7Tu1iLwLkxD2hzYap/M422Kw2N+A8eLGAZ/vKv83WOLIdamsSveUpJkkXc pGYzU+bZahdrtsikvdTLqDTMvRDLMHIuJWMQD+Esu5YvCGzzG0xaShxb4Q/SChcBhig== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=lsuvqAvo; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66DC560ABB04; Wed, 4 Nov 2026 21:12:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=lsuvqAvo Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2CE51F00A18; Wed, 4 Nov 2026 21:12:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793826763; bh=DvemVXISlO2P3Tj6vrQMxZUWeZt/QLe5Wd8LlKCSvVw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=lsuvqAvotXMyPio8NrxEus/c9hpjWBmBWrFlYP/iuMBJ2faSMkrQOe/KzeUrNC13y hFH0MOrsEuPaCZpG4/Eu0XtP40aHpeOiGrFySMi2+SyjCXDZKwZgVvoQqj/sqPGCfy 9ng1ScBYMiMs5a+bMRuCxydgEz7uZCYKUKLdVnpY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Baolin Wang , Barry Song , Kairui Song , Johannes Weiner , Shakeel Butt , Axel Rasmussen , David Hildenbrand , "Lorenzo Stoakes (Oracle)" , Michal Hocko , Qi Zheng , Wei Xu , Yuanchu Xie , Andrew Morton , Leno Hou , Sasha Levin Subject: [PATCH 6.18 0003/1005] mm: vmscan: fix dirty folios throttling on cgroup v1 for MGLRU Date: Wed, 4 Nov 2026 15:55:36 -0500 Message-ID: <20261104211043.619073508@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211043.516122098@linuxfoundation.org> References: <20261104211043.516122098@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Baolin Wang [ Upstream commit 13b6b620910436c29dea398382e83c9499fd13e4 ] The balance_dirty_pages() won't do the dirty folios throttling on cgroupv1. See commit 9badce000e2c ("cgroup, writeback: don't enable cgroup writeback on traditional hierarchies"). Moreover, after commit 6b0dfabb3555 ("fs: Remove aops->writepage"), we no longer attempt to write back filesystem folios through reclaim. On large memory systems, the flusher may not be able to write back quickly enough. Consequently, MGLRU will encounter many folios that are already under writeback. Since we cannot reclaim these dirty folios, the system may run out of memory and trigger the OOM killer. Hence, for cgroup v1, let's throttle reclaim after waking up the flusher, which is similar to commit 81a70c21d917 ("mm/cgroup/reclaim: fix dirty pages throttling on cgroup v1"), to avoid unnecessary OOM. The following test program can easily reproduce the OOM issue. With this patch applied, the test passes successfully. $mkdir /sys/fs/cgroup/memory/test $echo 256M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes $echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs $dd if=/dev/zero of=/mnt/data.bin bs=1M count=800 Link: https://lore.kernel.org/3445af0f09e8ca945492e052e82594f8c4f2e2f6.1774606060.git.baolin.wang@linux.alibaba.com Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Baolin Wang Reviewed-by: Barry Song Reviewed-by: Kairui Song Acked-by: Johannes Weiner Acked-by: Shakeel Butt Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Qi Zheng Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton Signed-off-by: Leno Hou Signed-off-by: Sasha Levin --- mm/vmscan.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 2c66fbcd6e845..c983815bde5bf 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4901,9 +4901,24 @@ static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) * If too many file cache in the coldest generation can't be evicted * due to being dirty, wake up the flusher. */ - if (sc->nr.unqueued_dirty && sc->nr.unqueued_dirty == sc->nr.file_taken) + if (sc->nr.unqueued_dirty && sc->nr.unqueued_dirty == sc->nr.file_taken) { + struct pglist_data *pgdat = lruvec_pgdat(lruvec); + wakeup_flusher_threads(WB_REASON_VMSCAN); + /* + * For cgroupv1 dirty throttling is achieved by waking up + * the kernel flusher here and later waiting on folios + * which are in writeback to finish (see shrink_folio_list()). + * + * Flusher may not be able to issue writeback quickly + * enough for cgroupv1 writeback throttling to work + * on a large system. + */ + if (!writeback_throttling_sane(sc)) + reclaim_throttle(pgdat, VMSCAN_THROTTLE_WRITEBACK); + } + /* whether this lruvec should be rotated */ return nr_to_scan < 0; } -- 2.53.0