From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 8B45A25B305 for ; Fri, 27 Mar 2026 15:30:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774625443; cv=none; b=c2JHJRqh1dVL3TCstABuhGy0VT2WifBMv9ClaDtjKCxXhBxNuHi3a0mxCFa8M0I7GmrcrRIAkHNSviXaWhiwJLEBT0XpTS4tWWUlK/WTdcqcZDJUPN3yCgO+is9XfMxcVMn5ixeTQn29Zh9DqP0nkk/o/9KHGbekPl15r3ArHbc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774625443; c=relaxed/simple; bh=SMebY9ZTaWWRA7SmqcieTLSkL0fd4WuEFVirgLwpLao=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=H2D+L+ZoAWL4vWKA/5f8o1uviZQ4jrq2kxiGhwBwbZKp7qY/WrsZQXgYBStr3A90SzlhdM2cyr3I1uD1FF4Yw0n3dd6z4a4T4wOdpXKIU4k5g0m0MohDuJtDM1jWxhmYaJYtJF/azWwrNTreMwyG5quBFYlx6OBRv2sLX0Lx25M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=dUTxbmCz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="dUTxbmCz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B87F0C19423; Fri, 27 Mar 2026 15:30:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1774625443; bh=SMebY9ZTaWWRA7SmqcieTLSkL0fd4WuEFVirgLwpLao=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dUTxbmCzVq3tVCuof0pebARQfRtn9eu+rKkqBqJ2Pk/19CZ9Bpmgd2B53lToz9Lr/ QaPM2vA1Ckq/bfCT2794y442mvocn3tQ5jvhRj68jBvOrOdS2HFF38yTznkS+Tv4Q+ QL+9GgwdMOjrwqt3TMu0ZQbqpZMoqn6S0PKeBzIc= Date: Fri, 27 Mar 2026 08:30:42 -0700 From: Andrew Morton To: Baolin Wang Cc: hannes@cmpxchg.org, david@kernel.org, mhocko@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, ljs@kernel.org, baohua@kernel.org, kasong@tencent.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: vmscan: fix dirty folios throttling on cgroup v1 for MGLRU Message-Id: <20260327083042.da4fd1586ab8aa2f639393b0@linux-foundation.org> In-Reply-To: <3445af0f09e8ca945492e052e82594f8c4f2e2f6.1774606060.git.baolin.wang@linux.alibaba.com> References: <3445af0f09e8ca945492e052e82594f8c4f2e2f6.1774606060.git.baolin.wang@linux.alibaba.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 27 Mar 2026 18:21:08 +0800 Baolin Wang wrote: > 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 > > Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") 3+ years ago, I don't see a need to rush this into 7.0. But should we cc:stable?