From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f65.google.com (mail-qv1-f65.google.com [209.85.219.65]) (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 CA51A1FF1C4 for ; Mon, 15 Dec 2025 04:12:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765771929; cv=none; b=KpHm+VVNVK1hlvAhP7pis4KGYO5B46l+mU5re7rXhBU3dE2s9oIwGeZJPu/iVwRc54ttthYC1pUyTqwNaIb3qrpAjDmOImG2qhjTqDSUQ0u2otL2Q63uPoAJaidf5y7W2gkXhqFrgM2DP9h16ZTDmXtJPvGlTwOhyrIqKRC09TU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765771929; c=relaxed/simple; bh=LlTy+URBLCiGF+TpnT1W4dpN/2LTjAki8y8L2YhWWVI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=n/YKkNWntrFqiukOSpm6+HtdVI58tXel2S8UZyR0Isit9difUz+YFWBj1LSLYPtgx9pJOH0445KZVdm323m1jZCbjn1sRTCuKfYG091DAO1KeSORt3Qrk2Ww4YHntd7Pqkohw7eqThrNQOaRUCZow+WfuAgmwt4B/dc178Pcsl4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=EMkwYMAe; arc=none smtp.client-ip=209.85.219.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="EMkwYMAe" Received: by mail-qv1-f65.google.com with SMTP id 6a1803df08f44-88a367a1db0so8071166d6.3 for ; Sun, 14 Dec 2025 20:12:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1765771925; x=1766376725; 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=E7DQ2g2y7DFnp+FRCa/U8wGU2Z4RUvLIQJbTa2M375k=; b=EMkwYMAeAL1mSfoI/CK2DnAXXSo5FtaUnjn+wQLyQY7Rj9Xqa0Qj42cgPIUpeMs747 CgFFIWvtnHC8u9WoDVUge20GAyKBaFaofbFEedaPkGA6vas9eIqNp8fHUnzlBRIaplGb Lst7UiimoGgTf11PqVdFtnG4X1QR/u6bvgMQhMwomnAgwHiKq7MUyVmDWe0W9CMeaqBW eU74efn+qWqPua0+coj3tnsuAIR0llJ4JJrbgKF6vVwbcFonr9LguMzuEg6D4GzOxmJg Q1szqPR8HPNaN9FXNzHDXM7UjktiJN8bcJh5DkRJeeW/xW09PcS3LEY2krfe8j89JSzj ZY4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765771925; x=1766376725; 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=E7DQ2g2y7DFnp+FRCa/U8wGU2Z4RUvLIQJbTa2M375k=; b=GiJU6JZMyMJN/mHUfFHNxl9ngdC28+KwlXUVTTLT3yEdEG/a5yjmCx1DDEUsNmOTAL YdWWiVAZ/IDflQS8woRVIL4nLNTGui2Owqe1TH0JktOPJZztgbX16l6w45jGUG/X/mvs 4wYC9aqgs0WKT4Y7KYx0WV7qD5haDVt5Qf0gfJtrLueJqhHBIZfIDIQeBNQuNb9gol5o gsJGuTTkGxovEq5RWO5VNlYULGHyXKV5s24ST20iv3un3fKzKS7X0elBt5OJtIOX/rXC v54ClvPcQhiW8dhMZlnqNJiNykYGcSiPMiBSkXUj5Y7L2PDFYCI8qiBZVZN4hf+ScD8Y DSPQ== X-Forwarded-Encrypted: i=1; AJvYcCWkr+G41LYm8b5v0oLG7oBdpE86QFDzjI+r9XUbXFhBeN2846P0HnbCfcdpjilu4bbg3GxoDG4qSPcbs/g=@vger.kernel.org X-Gm-Message-State: AOJu0YzXE4Py5SbzzAT3UnO33e8TJkhPLlJ7KXZHIKAuqFZFffVTCL4v VocmRdCZZypVrYWl1p88Pw7lMR9hi9OooIBqrp/35/fSTKtN7PkmW5ItODwqOdzea3Q= X-Gm-Gg: AY/fxX7nv+gPf1c/arUx3YhFssZDchwx+3OzCr/u/doD35lzAtGl6R6xT19UsiuBmcN g9Ypt6P4nYgZamTdJT+CXUhJr3GQIP6VrRyWyoxkzMr69RNxjVks8qfNaCqI/93T0q7ZCjIaqdN U0XwwHwW113/zd/bZ6GZW1tacGiEMRM27Swu9MwWMxktxq5AbcDPkfm+lcJo2y8C7EjnHZhvt3j /JiRny033fOwOpAFzhKzo4n5+omyQACnyQuwm4EYu6R7QvDGzbSqu3n0UstAzzwJtrsMXQDbFqW uKIOnBAlZB3rfd25m0bker2MCZVsmxnCwBFRW+kyqz3Y+TrRy4BqPAFtHL1yuNhGj4NAhHm/bhH pyClBH2f4/z4UQadmm1FR1ln6UjM5q0Cxvx62kK0TZlNAem0MPx+ojAd73U1mEP33XXe0Q/YT0w kRHVsmiU0mqQ== X-Google-Smtp-Source: AGHT+IHAmblDsUWWc7Lw8wQra+wzGGGtOdNSDrHzkr0iTOYEzvxfomHclZngzZVyVY6PMcP6p7yzfQ== X-Received: by 2002:ad4:5761:0:b0:721:a9d7:297a with SMTP id 6a1803df08f44-8887dfe0aafmr179128436d6.7.1765771925333; Sun, 14 Dec 2025 20:12:05 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-889a860c642sm42392606d6.55.2025.12.14.20.12.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Dec 2025 20:12:04 -0800 (PST) Date: Sun, 14 Dec 2025 23:12:00 -0500 From: Johannes Weiner To: Deepanshu Kartikey Cc: akpm@linux-foundation.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, david@kernel.org, mhocko@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, yuzhao@google.com, heftig@archlinux.org, oleksandr@natalenko.name, bgeffon@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, syzbot+90fcab4d88cffed6d0d8@syzkaller.appspotmail.com Subject: Re: [PATCH] mm: vmscan: always allow writeback during memcg reclaim Message-ID: <20251215041200.GB905277@cmpxchg.org> References: <20251213083639.364539-1-kartikey406@gmail.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: <20251213083639.364539-1-kartikey406@gmail.com> On Sat, Dec 13, 2025 at 02:06:39PM +0530, Deepanshu Kartikey wrote: > When laptop_mode is enabled, may_writepage is set to 0 in > try_to_free_mem_cgroup_pages(). This triggers a warning in MGLRU's > lru_gen_shrink_lruvec(): > > VM_WARN_ON_ONCE(!sc->may_writepage || !sc->may_unmap); > > The warning occurs because MGLRU expects full reclaim capabilities to > function correctly. The call path is: > > mem_cgroup_resize_max() > try_to_free_mem_cgroup_pages() > do_try_to_free_pages() > shrink_node() > shrink_lruvec() > lru_gen_shrink_lruvec() <-- WARNING > > Unlike kswapd or direct reclaim where laptop_mode's disk-saving behavior > is a reasonable optimization, memcg limit enforcement is a hard > requirement - memory MUST be freed when a cgroup exceeds its limit. That reasoning doesn't make sense to me. Reclaim is always in response to an allocation need. The laptop_mode idea applies to cgroup reclaim as much as any other reclaim. Now obviously all of this is pretty dated. Reclaim doesn't do filesystem writes anymore, and I'm not sure there are a whole lot of laptops with rotational drives left, either. Also I doubt anybody is still using zone_reclaim_mode (which is where the may_unmap is from). But let's not introduce more inconsistencies, please. The only thing weird here is the MGLRU warning. What is it trying to assert? Clearly whatever assumption was made here has never been true. And what is the zone_reclaim_mode (may_unmap) assert doing in the cgroup limit reclaim path? It seems to me both the warning in cgroup reclaim, and the goto done in root reclaim, are kind of unnecessary and gratuitously breaking both laptop_mode and zone_reclaim_mode - obsolete as they may be. But why even add this code? Can somebody with MGLRU context please take a look whether we can remove these? > Set may_writepage unconditionally to 1 for memcg reclaim to ensure > MGLRU works correctly and memory limits are properly enforced. > > Fixes: bd74fdaea146 ("mm: multi-gen LRU: support page table walks") That seems unrelated?