From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 AA55F3FF8B1 for ; Fri, 27 Mar 2026 18:00:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774634406; cv=none; b=tdikLvDbYIvamDNGiZ0QLyPNfn34mJdeHErOmCx7tjjuFJx/i3vgG49bfUZPd2LG4W3Rk+tsb+aU5qpFhOHVovgREXG8oHMOobEb4DJophS+jwtIchpljaNRU2j8DOanE03RBy+2twBxiGtSuYb9QqD+iWOFoe3MB8aqjQj3MEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774634406; c=relaxed/simple; bh=Bplhc7QkfTV4ixYG172BCkx3Z23JAQo9mMQRLiakdJU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IoXWsiyvczgja3hAR1VdicpQ+camKPR1+gpUiWsHrxFMIiNQDTF7kgU7GJJWTfo8UphunFdTPZ+QzgeQIW35w5UhqdA1/YWaQ6F46ru+NB/7LpeU+bCDdvB4UCJE1LKjaivxqvsLgFB9AZT7asqTog+/JpLBPiv0WZscSw4216M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Dhuyn7ZX; arc=none smtp.client-ip=209.85.210.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Dhuyn7ZX" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-8298fad2063so1452505b3a.3 for ; Fri, 27 Mar 2026 11:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774634404; x=1775239204; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=psRPCm+63S6VKzTyhaTnVC2SxoOiTOnf8ReGI1/gkuw=; b=Dhuyn7ZXopFKc83XUUnF6SxpurTl8kb07v2vypKupWANGjYiJlLo6oIzgQWNqUTy/3 StljoX82/o0MXvrG5ZRzjC4AphEcghbKCr98/iE+pibgNo55L76Er5FLQ7jdvrNQCOeA LNmsf82XbqiMqLwZHyrK/Q/Q1qlZFSunpyhJ20L5mQyRIaZu9fMtuowFHmrN0Ax71iIr XZEBvTY/ekvyQ6waMLIdokThW489lAC395Fxq2KOj55kx59mp4TED5I4kxlLseespcdi XwqxqSf9jz4IIGBQ0NHePkaF0mDVj0pmKNKT9MXU15kuX6vOhnwUXdNwT9qwq/DC86fL qtpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774634404; x=1775239204; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=psRPCm+63S6VKzTyhaTnVC2SxoOiTOnf8ReGI1/gkuw=; b=cj9iQxtExittfKZ7Y1B1Uknlfuy6QCPj5hzoAYUc9hkTIi4p7PJq+wiBmpbadnMo2V w+qYF1ZyjPMQiHcx14AcSyY4XRGdqpAiCVMhJ3F7N++RmNn8CrJC6goFwR8Us8eg2AFr k7XHAHwHtZJq1vTbPqegk5DnAW9ZQd0cs76O/hoT61D+MLLhjDAv9W92uTzUPxPQfcsi xuYE1OahI10adZE512Tv7kXm+avO/XNQSgRvBHoh3liwslavtk9H+hB93VI43IVcYvRp aR3qM1WgE5o2oJzfWug/lXcCmv+OqhWXXwgDdowW0esW7qE3m0YW8XZm0PDD0Y2XkGI6 9sUw== X-Forwarded-Encrypted: i=1; AJvYcCXfr03/1mSuOd6z5cL6QzMZ2fEd/mLmjvW784udpfNFiF9B23luQfcNcephj+nTYXjAJGnULTsQoFxT/aI=@vger.kernel.org X-Gm-Message-State: AOJu0YytUs1wRbUj+oKC4u2FUtO191RTgcJiffAYeSnJZv+2TIyNceH9 61mQ4yQaamRAkPOOuRobfhec1MsYpZ47EOvqe6bH7z0SOVnbhvw8oe4u X-Gm-Gg: ATEYQzw31E+bkw57iU/BKP4MAs916ldzEiOrkQa91kCR8jiiiJ7qTreLGDEErM7oooy 1WuVOXbhZXTPvhvazLAhY5LpjCq+ffZNIfxVMnl1gja8BgBw1fWz5b5gu926vbe60mlosRmUXFH 5FSeJkBYEA8FraIiJ3IuoiWwxlWO468PzSV4CH+s0KH0mb+lAzWgzUttF5blHoonv+jYTmNDt1d wrAeuoJxb5cJqtU5iHzTyc1HKwL8CTrFYcqtf5Hb5fFg9XQGJo2bSxLynvyFJnzEvcPhUe2tZ4Y FzZiwFmlZ9ILaXkm1DZH8fML695hMiA1Gx1ZsSEn6q3yF8w5C1DS3uaRFB5Sr3h3jiNqAZlYhJ/ TLWyy4kuZQvtwD+t8IR8debdILbaa9v5XIfI9IQx4Zi5LLmqhZ5bXmQuOTrIATClP5DXF97n5At SG06U6I0kz7+ibRPBwEy5ChTuzdsT3N7DJJFHIxXIRBA6A6n5mgTax84a2HUxquy1OkKeceg== X-Received: by 2002:a05:6a00:4095:b0:823:3079:7c7 with SMTP id d2e1a72fcca58-82c96001c0amr3363107b3a.29.1774634403774; Fri, 27 Mar 2026 11:00:03 -0700 (PDT) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82c964f9e9bsm2601447b3a.49.2026.03.27.11.00.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2026 11:00:03 -0700 (PDT) Date: Sat, 28 Mar 2026 01:59:57 +0800 From: Kairui Song To: Johannes Weiner Cc: Baolin Wang , akpm@linux-foundation.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: References: <3445af0f09e8ca945492e052e82594f8c4f2e2f6.1774606060.git.baolin.wang@linux.alibaba.com> 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-Disposition: inline In-Reply-To: On Fri, Mar 27, 2026 at 12:41:06PM +0800, Johannes Weiner wrote: > On Fri, Mar 27, 2026 at 06:21:08PM +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. > > This fix for cgroup1 makes sense to me. For cgroup2, MGLRU shares the > shrink_node() reclaim throttling. > Ahem, I think that throttling is actually broken and so I'm fixing that, I shared a patch yesterday for that as I saw Baolin is fixing V1: https://lore.kernel.org/linux-mm/acPOn07xah2eh0WU@KASONG-MC4/ Still need about ~3 LOC change after the patch above since I also need to clean up MGLRU's force reset of PG_reclaim, will post it tomorrow as part of the V2 of MGLRU's dirty folio handling rework [1]. That series will improve the batch and dirty handling so fixing that is much easier and cleaner by sharing same routine. Before that series it could get very messy and cause over aggressive throttling. Will post tomorrow as my stress test suite is still running today, it seems all green so far but just in case. I initially want to post that after that series but Ridong suggested to just fix that too, and it actually helps to deduplicate the code, the change is also small. And right, MGLRU had some issues with dirty flush previously, Jingxiang and I fixed it: https://lore.kernel.org/linux-mm/20241026115714.1437435-1-jingxiangzeng.cas@gmail.com/ But premature OOM is still an problem, not only about dirty or writeback, but also somehow related to how aging and protection works. That new series also fixes quite a lot of these, e.g. the OOM reproducer in cover letter. https://lore.kernel.org/linux-mm/20260318-mglru-reclaim-v1-0-2c46f9eb0508@tencent.com/ Still not perfect but no worry as we will solve all of them (hopefully very soon): https://lore.kernel.org/linux-mm/CAMgjq7BoekNjg-Ra3C8M7=8=75su38w=HD782T5E_cxyeCeH_g@mail.gmail.com/ My local reproduce using dm_delay and dd can trigger OOM without the fix I posted above, and no more problem after that. I guess storage nowadays storage might just be too fast and it rarely congest the whole memory so no one reported this yet. Of course it is a real issue. We did see a few suspicious OOM, rare but might be related.