From nobody Fri Apr 3 01:23:04 2026 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 7AECA282F14 for ; Wed, 25 Mar 2026 11:50:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774439462; cv=none; b=liYuxyYUo/Mz51pLGpqCYBUCb0bx6dWPka6MM+e7dwbW106nxR/mHRn44+hBhsZ5gXxqCVh/gu0GEZaiPY0+z6ULt/UvBVHMQ3uxw1VTJ/S4g54wzQiBMDPh9t+FLmzcph3+8u+DkkeaVtKP2u5bxscH/B1uuga1Cf91JKQvT+U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774439462; c=relaxed/simple; bh=IGNjxAH4uhncyFrRPWW0blSMUYluoGhp2dPKlmZWdtA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RhlKYBzi0cRt0CnrClDsR9ZNJUvGC3xjKGEYazVxaEXo/izygKcNc5PQaZbQRX27WISwty/2nf7MdG3u4YwwyoI2fqnoVqxLTQmHEBstP6YaTXX36s4jIUS8Hsc86gnWIncEbeg8SYvlozX1lFBOMQmBhmCM2vq4eThxnp58s0s= 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=Ndyggtje; arc=none smtp.client-ip=115.124.30.124 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="Ndyggtje" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774439449; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=fh2m+bR/6D39zNLTgYdahtwpo8phH0yzMEjKHobAvT8=; b=NdyggtjeqhCBeBMVlmDpO/gtbnQJYFoPRiF7pV3o3PMGPx+OntZyaEKogo8DZY6+37rlz4Rjg3J+v5R/OJwH3PudmLK5q4RFanUmEi6uVE0yoaiynjMvs/lcGClDw9eF7H1NKA0Kq4cfq+N6pC32ZnYGLs3OvB+3HSxQ3fInqUk= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R591e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0X.hZLU0_1774439448; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X.hZLU0_1774439448 cluster:ay36) by smtp.aliyun-inc.com; Wed, 25 Mar 2026 19:50:49 +0800 From: Baolin Wang To: akpm@linux-foundation.org, hannes@cmpxchg.org Cc: david@kernel.org, mhocko@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, baohua@kernel.org, kasong@tencent.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH] mm: vmscan: fix dirty folios throttling on cgroup v1 for MGLRU Date: Wed, 25 Mar 2026 19:50:40 +0800 Message-ID: X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 pa= tch 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=3D/dev/zero of=3D/mnt/data.bin bs=3D1M count=3D800 Signed-off-by: Baolin Wang Reviewed-by: Barry Song Reviewed-by: Kairui Song --- mm/vmscan.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 33287ba4a500..a9648269fae8 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -5036,9 +5036,20 @@ static bool try_to_shrink_lruvec(struct lruvec *lruv= ec, 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 =3D=3D sc->nr.file_tak= en) + if (sc->nr.unqueued_dirty && sc->nr.unqueued_dirty =3D=3D sc->nr.file_tak= en) { + struct pglist_data *pgdat =3D lruvec_pgdat(lruvec); + wakeup_flusher_threads(WB_REASON_VMSCAN); =20 + /* + * 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()). + */ + if (!writeback_throttling_sane(sc)) + reclaim_throttle(pgdat, VMSCAN_THROTTLE_WRITEBACK); + } + /* whether this lruvec should be rotated */ return nr_to_scan < 0; } --=20 2.47.3