From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f193.google.com (mail-qk1-f193.google.com [209.85.222.193]) (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 6820E29E0E7 for ; Mon, 15 Dec 2025 20:22:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765830140; cv=none; b=J2zb9XcJU3BBPdDhtMBPPX+RPr4J1fk3SU3yTcdPPGaG3zeU++OXKKUuJp37fVhBXCXNtc43JD8Jy4OxcXKuw7upc0KT1n+XLZwo49jOs2ObBGVR1v1IoGQRIw56w3f+P+9MA+mByiGxqBYBuA/ScFx7Lj6n0DyviTuLtZBEHbk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765830140; c=relaxed/simple; bh=rdwGf2I47a5iAgZxBKk7hnanxOADD0Nsjp8Zy3wLs/s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=A7gk4xRiPjv94JtMv0AiVsIuCULNSmuRTt4fOZg3vuKh0jvYsTGMFAhY07cBrYsT7uQLPN7BfDcgRrk9FFhV8vKPaXrGfWmnXa+/R9/ps6cowyzP/SCU29j4SdShEZkfXe4hc7kVi6QqW3jiQtvpMvlPRYd7j5ddihvGoP68n9Q= 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=OQ+rKuci; arc=none smtp.client-ip=209.85.222.193 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="OQ+rKuci" Received: by mail-qk1-f193.google.com with SMTP id af79cd13be357-8b1bfd4b3deso329513785a.2 for ; Mon, 15 Dec 2025 12:22:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1765830137; x=1766434937; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=+y/OExnZJdz2I4sdpnCKdx4pnmEb3dzMAfFUovxakG8=; b=OQ+rKuci05YiHcSv4/sKN8E9J6Aq9sEWLDLLSzVb0Q7Yx4cW+ebvpwe6G0wirJEO49 WpTkWm+Gj+X48SQRPWBYxHy0mjOQA8ZzmyfBFFpShqjlHij9+WOcPrcnIG9Ukhfmfe87 dkMsldB5A9qs8IA5gtjxnWLhLbdxvE0Cx9FwQlTjaCeMmP+3vMgbBOxzaaaA87CTMir6 V60mWZuVZLgcxCrM3yhIHbVCfpYZr3dGWWNYRf5iRxC+fEsGcXCmtYsBN9Bua4+qiPws NdntfHoPIRu3uycDCFRFmLIF+bHHZEnGywGCECZ9Viy3fEkZtmhSUgKTo7r+VdLRfvAY +FMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765830137; x=1766434937; h=in-reply-to:content-transfer-encoding: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=+y/OExnZJdz2I4sdpnCKdx4pnmEb3dzMAfFUovxakG8=; b=v8AVGdgOwpDX6nf+Sq78g6o3RYv0VgGF3gasxQ0y8DAByh7LdVNGfIS0+vlGTzetLy u+bb/EUf3CEdzOA/bCT/IlwkcB0DADSC6AwJMrfJ3d3D+IFN6i6APKlgnK03wNBc2302 bhtJfr4PlxBQ0WBoSA0rhIQrOQmt6FcvoW3+HjVdL+5SRXyDYM4AFcpm+3UZoWCl+eC2 XESawfZ1YRSI0n1s2zuKUIOEnNhdbCRS2jMz9OlcV/ZyLniJAhbC7TkZo7NuQun4qaQ5 734W5fp7srx7dQv/EaouQumoZOjc9dC5+q6O9OJVpNMNOIbdvrAknGiNaWM+dp1+1Dj/ c9WA== X-Forwarded-Encrypted: i=1; AJvYcCUPCjoNnuOfs81iOj7p7MndGBgQgyUdAIrmTPg7rgrQ9bldQ0vN6W8p1INAY1v25RnGm1prae4wiNrvVk0=@vger.kernel.org X-Gm-Message-State: AOJu0YwMfdmGDkd60Z7s4IBjgrJaV04Er6MbSXxkVjfRWbi/BE1lRWzt Q/9HqQldEp5tfhvB4m+t/eNqMkmyhgRBbwlMTSirq7PaqL/CK4tDFu922fvxW1Kjlzw= X-Gm-Gg: AY/fxX4nsAIEbLA3C7+DHvESgqQ9fWPYk+FEZwB9uaJOoO8gY2CmTQDSug/sWn8KIv6 PHF12l2VpDYXi4+q8CFQvw/nks1+cJFnW7oLcFe3wkyDJqJqEv6rIG3WDsgd3f9y4HFrLQIzTmN vx2U0vvpb8H4Mf1UNtbOQs4yPmH7Ae+q9U/QWfJpAkR/JxDa+fHwkBdpj+be+3cR3z5SMgTZE7W 3tFPWzRqrkvDzI8KEXKXsRcuicyy4ByyJEc7SjGdlEbyqqJWGyqGFYTLQgxxUFulQhOZXbKdz2G wZzbn8XTvsezmSw3ESVyBC26wPnJdKNDN+ZY04EBv3j4f4WG1/mjnyDDSlo6Cy9dgoeDtwotxIA 8/mV85nTxpd90PCtsVgemHZLoc/w0BryFsxAxWaNjcHU3uxfXQeZLCgN7piwWddc5qLXCFb7c/7 Q4fpTUhxTxRQ== X-Google-Smtp-Source: AGHT+IFB0yWAs/WQa22s4hXXN/WjgCrjXwhkmj33fa4e6o9GlD3XRiZMrt6K5AEN5A7fpG0KHFBCbA== X-Received: by 2002:a05:620a:19a3:b0:892:501a:290 with SMTP id af79cd13be357-8bb3a39bdadmr1752551085a.86.1765830137060; Mon, 15 Dec 2025 12:22:17 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8be303e7bf3sm27079585a.6.2025.12.15.12.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Dec 2025 12:22:16 -0800 (PST) Date: Mon, 15 Dec 2025 15:22:12 -0500 From: Johannes Weiner To: Yuanchu Xie Cc: Deepanshu Kartikey , akpm@linux-foundation.org, axelrasmussen@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: <20251215202212.GD905277@cmpxchg.org> References: <20251213083639.364539-1-kartikey406@gmail.com> <20251215041200.GB905277@cmpxchg.org> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Dec 15, 2025 at 01:42:27PM -0600, Yuanchu Xie wrote: > On Sun, Dec 14, 2025 at 10:52 PM Deepanshu Kartikey > wrote: > > > > On Mon, Dec 15, 2025 at 9:42 AM Johannes Weiner wrote: > > > > > > Fixes: bd74fdaea146 ("mm: multi-gen LRU: support page table walks") > > > > > > That seems unrelated? > > > > Sorry for the wrong fixes. Correct Fixes: ee814fe23daf ("mm: vmscan: > > clean up struct scan_control") > > > > I'll wait for input from someone with MGLRU context on the broader discussion. > > > This warning came from commit e9d4e1ee7880 ("mm: multi-gen LRU: > clarify scan_control flags") [1]. > > The original rationale: > > 4. sc->may_writepage and sc->may_unmap, which indicates opportunistic > > reclaim, are rejected, since unmapped clean folios are already > > prioritized. Scanning for more of them is likely futile and can > > cause high reclaim latency when there is a large number of memcgs. > > As far as I can tell this was a sanity check to ensure > `lru_gen_shrink_lruvec` avoids extra work for minimal gain. Perhaps > this shouldn't be a warning? Always setting may_writepage in this case > would free more folios. I'm not against removing the warning either. The premise doesn't seem correct. Aside from laptop_mode, they're used in those scenarios: - zone_reclaim_mode: local node is full and user would prefer clean and/or unmapped pages over spilling to remote nodes - watermark_boost: the page allocator finds itself in a situation where it needs to fragment pageblocks, and it calls for additional reclaim to get out of that situation Neither of them are opportunistic. It's user-requested behavior.