From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (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 1A446397688 for ; Tue, 3 Mar 2026 19:35:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772566520; cv=none; b=Pz2mNclmTqSqO5rNmg467G0EMwBdr2SbvHOKP5goilHXKV2JeG+a1DELdf+R7+AdjjqJ1dUdIOEYekRdEAQ/ethDmNTNHEcg3wOw7KTpctBFzrcbvBcVxqtCy755SqjdIUyqMjltBvK9upuC/N3Dka9sndDh33mu8H4wTZyURDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772566520; c=relaxed/simple; bh=xTHkte2RUvSWtiFL+zim574JKvRQEGOa3ktAOhw9pjM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gPRUhT+NLVSCB1ymti07HxYtiYRjRqKjvHfa63axbkaCbn0ysjbvSix5AMoKsoklfYU7OG4OdGAEQPmYJ4yC1LmiBzGLqEH9I+9a8jPE+JTeXMsrynRedMqf2YE9Dk25AE9JH91X43go62EsU70xJ7MtSKAwPzOOekY/AHXv220= 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=uBvvwSOv; arc=none smtp.client-ip=209.85.219.44 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="uBvvwSOv" Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-89a0d53f3d1so9951076d6.3 for ; Tue, 03 Mar 2026 11:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1772566517; x=1773171317; 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=xTHkte2RUvSWtiFL+zim574JKvRQEGOa3ktAOhw9pjM=; b=uBvvwSOvBLhGkAa1GOmTMqRh3KFBIk3CR5QIlUEXsdKSbq8+ugoWCfnfrVZM1n7mzl pNeWGvrpwRJhy5ESpvb1xy/lNb/FXSXfY6xYfOo5d0dtvlhggylRkOBcw1kVghO2KNNm /Ru8jR0aLfw8g6MyIo+DvLWYUZqrwZoz2sD7SB2Lw11qj6Tr4Z/vzg93vIwp1pK4gCwR v+bQvW/h2vXV+xPXBgv1v5/v9bxt7q3XRbM9VyDUugDvvPPAAqNmjPZyZTC8AKB8Sp8/ PHOAiDiQGXWUTR7pB9W20OcaEYMRqv/7ThiaeVB7VDiSaLHtAaK4BMLY7uZqOTtUCyzc kt3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772566517; x=1773171317; 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=xTHkte2RUvSWtiFL+zim574JKvRQEGOa3ktAOhw9pjM=; b=e39TSIHcMvhSUUlbmVNNIyfJJkycJkyp3sYaGONiyyJF1tVcCU8rXO9YwuvpYQ8PX1 MtyhT1Li4dP5DquW4i1dDgLhh7GNYN7fVoxh68RNSKReWQevvQxS6rcI9KeRoO6NUmzQ hlzofWDaUK7eHo7TavGGrM28vxjzYtOzQBL49Bnv1wipcFcLpBlnPCAO5xWUyhe7mL+C u/OYuAZgD6kOnhHAsZxhGUTiA22rj/MVQmVSec7aFiXxqygIDYScJeLUbP0Gss0Fm+UV RGWSiUIfPyueqM9tkCLOLG+J3apgcewLN3aNaD710ubRe5c6FfPAi+m8GUFi8qsSbIr9 13Fw== X-Forwarded-Encrypted: i=1; AJvYcCWCao7xlheTEYu6B55//pMiHAKH77wyQHLkIK3M0SeWTAiYFiJuonh7T9+qgsnWmijEgfp/41/D2CFup8Y=@vger.kernel.org X-Gm-Message-State: AOJu0YwmcMz095/j3LiasmZwcsOt6vTrfr+Nj12s/3QYqJt/MeYHHgG7 T0QQqmDtBgSsStSFjCq9/GcvYxrS7mpyQO7bctqgJAbJyT0M0HhyHjQOKvPLTS6cSjY= X-Gm-Gg: ATEYQzyJ7wTV6FNGvYP8NAD7/faIrvEN6UWbWnplrMrc60ciSzSAI+lw3YKlmmPi+dD zJM7Ad2Vct5XeDaGBPosUCMxUQYtuNQ7drUksloXWQFpzZH8QNd9isWCYN7gesGivUiK1iQTWZx MWqR+7S3cQpH+fleYdBc9GCyigy8WzbvuA1Nzm+HsPBHwV6XU4bXHf+ZtDwWwZeBglnPWRt8e0u JczGjAJS5H3431k3peyUl5m/qKCOf82K+ZrmI1Le8ZEDerfGW6peW9Rpm0gcGnizKDsq/8lPG/p eQKBYlbGzrkPB0rlN+BlMpJs427O/W+zKresqqm5gn+WGP/ULMDeBqpQ5Snmd4QJ/A5USEmLTom bvBccKgIzvXc+UllIpgH7Toyn7Tqv5jrDm6JfMZBMShfCQQuAEFyYLmaQMP+IoT19TAN8yicDrk /YCbomyyilFwOeDUalHhGN+g== X-Received: by 2002:a05:622a:190f:b0:502:98a3:3496 with SMTP id d75a77b69052e-507529912c6mr206565681cf.45.1772566516729; Tue, 03 Mar 2026 11:35:16 -0800 (PST) Received: from localhost ([2603:7000:c00:3a00:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50744ab2fd9sm133192891cf.19.2026.03.03.11.35.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 11:35:15 -0800 (PST) Date: Tue, 3 Mar 2026 14:35:12 -0500 From: Johannes Weiner To: Matt Fleming Cc: Andrew Morton , Jens Axboe , Minchan Kim , Sergey Senozhatsky , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@cloudflare.com, Matt Fleming Subject: Re: [RFC PATCH 0/1] mm: Reduce direct reclaim stalls with RAM-backed swap Message-ID: References: <20260303115358.1323188-1-matt@readmodwrite.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: <20260303115358.1323188-1-matt@readmodwrite.com> On Tue, Mar 03, 2026 at 11:53:57AM +0000, Matt Fleming wrote: > When all active swap devices are RAM-backed, should_reclaim_retry() > excludes anonymous pages from the reclaimable estimate and counts > only file-backed pages. Once file pages are exhausted the watermark > check fails and the kernel falls through to OOM. What about when anon pages *are* reclaimable through compression, though? Then we'd declare OOM prematurely. You could make the case that what is reclaimable should have been reclaimed already by the time we get here. But then you could make the same case for file pages, and then there is nothing left. The check is meant to be an optimization. The primary OOM cutoff is that we aren't able to reclaim anything. This reclaimable check is a shortcut that says, even if we are reclaiming some, there is not enough juice in that box to keep squeezing. Have you looked at what exactly keeps resetting no_progress_loops when the system is in this state? I could see an argument that the two checks are not properly aligned right now. We could be making nominal forward progress on a small, heavily thrashing cache position only; but we'll keep looping because, well, look at all this anon memory! (Which isn't being reclaimed.) If that's the case, a better solution might be to split did_some_progress into anon and file progress, and only consider the LRU pages for which reclaim is actually making headway. And ignore those where we fail to succeed - for whatever reason, really, not just this particular zram situation. And if that isn't enough, maybe pass did_some_progress as the actual page counts instead of a bool, and only consider an LRU type reclaimable if the last scan cycle reclaimed at least N% of it.