From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 4DF6E36826E for ; Mon, 13 Jul 2026 11:20:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783941612; cv=none; b=Pzs4Zp4Y4ODjLnx/vl0sPQkh5ZNkmY7a3a9q/qh574dFbN+ix3rVk1sxBz26Xu6F5Scy/ahakqqJEGkN3lwPapn209k4m3MEzdCumUnQGCENyoXKezGD5sL/eWT6PLB7Q1vPr1ergURNRQVSC8FmBeXys4iA+0/XivMNvsDFKuM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783941612; c=relaxed/simple; bh=gM4pomRuc569b3T525bDsNAj51FJrNZZ/rHDdJNnHHU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c+kdlctQEb/sxi188c163LPJUp+QRf4NeiQIHeAUFF/edTbE8VHCckDAXyeJ/d5464oqNT5EoXyGXuIbJTiiOFp7KO9l2aMmvtgBZBj85uN45ExYyOmGR0SJIENhbgyu0dDmubdQey3BqlvPqiHTaEvcaHiwizy+8NrV56mBGqA= 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=cRlsmo7K; arc=none smtp.client-ip=209.85.128.50 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="cRlsmo7K" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-493b1710405so15518855e9.2 for ; Mon, 13 Jul 2026 04:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1783941607; x=1784546407; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=YvoD80vsybxHSm652w/hIfqV9kviycKG1qubWHSi0IA=; b=cRlsmo7K/2q+6pFVeshwbTezDUo+ug3KFcXFyU1S6LSWmevy8RCnFtz+gq5szMtr+I GA6DwCVy0u1DUgATkmFsXdnAC2IglX1osXu9IoPsRi1iG+uuaoQ20W06NslGD6i6ZEZp W+/TxaMQ6rQ4Af7wxq+2nyb8nVr2nLmPu6ARVO45Uq9Y1i9sMtXfjNRZIvn7v+ILPUWs PX7yXGnld9me9qkDnEJ8FRyFI8wmeod6cKK9ikO1sTdl4jP2d6aWcae7MRYAbTOm7y9U 3xr6rb02fZUhdD8qRDnFdjFpo4Ryrm/NJ8QK/eudAvbvfwo2NqJvPxmKfNV9LolQjRGG LybA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783941607; x=1784546407; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=YvoD80vsybxHSm652w/hIfqV9kviycKG1qubWHSi0IA=; b=DmhEbjGd3uPmNMuL8Z+DG4BcJChBvN/3M4DvapOi/vcmWc5WFCjf1SMeJ3RT41WZAf xy1dN7zyNFlt88PgcZrznTZevhz0+q5lSSl3Xs8ai7MMePuWzs1zk/DXdunL0rCnQ49P AZDWuFHIaXuleWj3UGdj7LI7BwvOwlRnEtsQoRFsISFeUgNi5x5Qb6b6v7qtWJTfsnD0 7vOIQ5HlqMCQvs+kCqXdGETaaC/1vGfERuM0kADMBOKC/NLlQDSJtorJtJErX57y9EC+ JlqkAoBgt5OcCsrkOWKEoccZQ7cSLxFeKvjJb/8U0NoeP22q6Zy6624c/ShBC1k+BF2k YyyA== X-Forwarded-Encrypted: i=1; AHgh+RqpnP7OQeM8d6GdiG1CL3mIoX+twxUOBFGW5YBLFBsh8vQrsVZuEFwO3gWgr9rhFG4bg73I35vD7mDW9H0=@vger.kernel.org X-Gm-Message-State: AOJu0YxargLPZnSzAI+5iggOPkdNO3/mqBKhHamtER8U1YXlZYaMpna0 Xn6WKtxrF/57nxhsrG4o7B6eu6yhG0gWPWQtPWz+9fX97ofs+qNpVWd/88A9VpOkHR4= X-Gm-Gg: AfdE7cmk4I2YksUOeCKhg5iHhOEzJMiyfKboDIFLK9IPaFHKPtXRllTbVZZE/+YmL8C /BSFG+N6ZcuxYbeu1hHVec7+Sm6G0LgEWYLTXnNgztzjnLhBXECog6jIs+hKGD+XodHtqpZUf9T K7TE+s+T9UjKsHzrpcO2kTNIUja+pcTSthnFgdyVFl007Aq8jArCCB3uMsm7nXZ31QmtrgYFvAt ay1LowsAbfb511Il0SaCJ6FyOOdKTPBMVfHOhi76Lq4yN9lVTYNK8IWg+gKtuUK3gcuQX5ADNuu WH+VwUXyO1dOavtyJ07V5qv1+KdM0EKjklA+c6uBh4ozuTYDUPhsIxsegzJfyPYTjdQIl+G+Kie gVBGghM6pO2xOsYqER3NMzhT7TOkPFUUrbfuu8kVyiQu5qrPFlZsK/j6n+h+suu8pdksf8OCXyU Ow5UeOyZ5T7PCINg+0ZKBu X-Received: by 2002:a05:600c:628b:b0:493:cbdc:7cd6 with SMTP id 5b1f17b1804b1-49400dc175fmr46864315e9.7.1783941606886; Mon, 13 Jul 2026 04:20:06 -0700 (PDT) Received: from localhost ([2a02:8071:6401:180:d892:bf43:a0b4:83b]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493eb6ff6casm425641675e9.5.2026.07.13.04.20.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2026 04:20:06 -0700 (PDT) Date: Mon, 13 Jul 2026 07:20:01 -0400 From: Johannes Weiner To: Altan Hacigumus Cc: Andrew Morton , David Hildenbrand , Kairui Song , Qi Zheng , Shakeel Butt , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jiayuan Chen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/vmscan: clear hopeless kswapd when global direct reclaim makes progress Message-ID: <20260713112001.GE276793@cmpxchg.org> References: <20260711043946.68421-1-ahacigu.linux@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: <20260711043946.68421-1-ahacigu.linux@gmail.com> On Fri, Jul 10, 2026 at 09:39:46PM -0700, Altan Hacigumus wrote: > Direct reclaim clears the hopeless kswapd state only once the node > becomes balanced - added by commit dc9fe9b7056a ("mm/vmscan: mitigate > spurious kswapd_failures reset from direct reclaim") so that cgroup > memory.high reclaim cannot repeatedly revive a kswapd that is unable to > balance the node. Before it, any reclaim progress revived kswapd. > > However, this restriction also prevents global direct reclaim from > reviving kswapd. Under sustained memory pressure, global direct reclaim > may continue making progress without the node ever reaching the high > watermark, leaving reclaim to allocating tasks. > > The effect is visible on systems where a database workload mlocks most > of memory and the remainder is under continuous pressure: allocations > stall long enough that ordinary tasks (e.g. ssh) become slow or > unresponsive, while kswapd sits idle. > > Unlike memcg reclaim, global direct reclaim follows the same node-wide > reclaim path as kswapd. Clear the hopeless state when global direct > reclaim makes progress, while continuing to require a balanced node for > memcg reclaim. kswapd_try_clear_hopeless() becomes static since struct > scan_control is private to vmscan.c. > > On a workload with most memory mlocked and the remainder under sustained > churn, with swap enabled, comparing the same 60s window: > base patched > allocstall (all zones) 413441 6532 > pgsteal_direct 15889552 255619 > pgsteal_kswapd 0 26079382 > PSI memory full avg60 13.10% 9.37% > > Direct reclaim was already reclaiming many pages in the baseline; > this change lets kswapd resume doing that work asynchronously. But does kswapd actually stop? I don't see how you avoid re-introducing the issue described in dc9fe9b7056a. Direct reclaim picking up a few pages is no guarantee that kswapd is able to restore the watermarks and stop running. The distinction between global reclaim and memcg reclaim seems handwavy to me. Either can free a couple of pages on the node. Who is doing it has little bearing on the question whether kswapd can balance the node and go to sleep?