From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 947D83E122D for ; Thu, 16 Apr 2026 14:54:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776351283; cv=none; b=G1nnCeviSIMffQVjhUtrs3OysRcPIgWFTWx3pkfd24lx2GOFZKZo1p4JxxSRgd/yzoBQrRitbxvkp1zeuWfL00Q8jCVa5SQ5fivRUprQl0yI1EMZoNcf6psKPJp0tBjHJA/D61I87hktR2+RLWlwZSC5n2ISE+GdrxqHuUIbQrs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776351283; c=relaxed/simple; bh=/q191nEXMphXgc3lslpHWjAtNOxMWMVdttAUMkifPq4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fvT8Ksgj403lDHvrJjAt3p3Vfi8S8tXEAksCQJ3pF0K2K+zSzoob3nN3IQYuo6j8YTqwk3oqf90vMGj9kD1x0Pjp7eq30Agk/e9tKJxX9ycqr64foz8CmxyJvpf5xfav6A91qZ7cZLFBBxS4ym+AvVSmDT0L1V5sOBuvcwN+SCQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=readmodwrite.com; spf=none smtp.mailfrom=readmodwrite.com; dkim=pass (2048-bit key) header.d=readmodwrite-com.20251104.gappssmtp.com header.i=@readmodwrite-com.20251104.gappssmtp.com header.b=SuAa/gHz; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=readmodwrite.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=readmodwrite.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=readmodwrite-com.20251104.gappssmtp.com header.i=@readmodwrite-com.20251104.gappssmtp.com header.b="SuAa/gHz" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-43cfce3a195so4957765f8f.2 for ; Thu, 16 Apr 2026 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readmodwrite-com.20251104.gappssmtp.com; s=20251104; t=1776351280; x=1776956080; 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=h9ArDot26j/SH+ZznkdYubmynXqAUZSHKndJja+UouM=; b=SuAa/gHzpCDKwYyEN0ZDZBSoI0yiv0oc2GEPjUFroBFfxRPCBHlQQZX5Nrt+N3507h mouOxiB5tDNfoUo+kdIHbrRVy7G9gwyAA3GBYpxY271/jwy7Aw7PU33NV4n4kOMOiX5i prJeyuUWkaqIvRfGdIDmHOnQG498pBQOEjjUsyln7+WhESgRBz4L8Pdw7J89EWx0Qwkp sKOYr9JC5RFWW9aP7RHYVYstx3iY4GParvHTNWXoc5Fda6tQAxSPcpMW1iDARmiJxuwe ggElNyjXiDQ+AdwRq4i9cfWRIJ8WwHfDBeQ7zlO2Q3UKlfxzpznJH2GPHS3pbIT/z8ma IpVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776351280; x=1776956080; 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=h9ArDot26j/SH+ZznkdYubmynXqAUZSHKndJja+UouM=; b=jqfPIwwtUZS4yGA8LSdPEksiVaEJiSaDDN1GowmYcH4cvsxam+cQm8zYM2vNxVt5U2 N57fxjmJ8clpccS99sQkKiQMYsZXmAhjfE5tUoJQ8ZYA05nGqu/qXWagKWUaxgREN3Gi GgBfCJe/wUF2k+wYb5vciCPBAqCaxYNwnEVO3B1PinsMaXRJ9/6LAD/SxU7U3dv7kuM8 hm5MStvjGjvHJoSXwbWh8PyLFWfWivBumiIixiWFFS0lo1lrSKg7dQ+U3DIOZjdLWoM7 +THYkgqIzdK9pBkZzLZW02vp7IBSuqf4Xv1GzdMd/KCtJatw8ECbiOZCCtQgX5Fd4KPb lAdg== X-Forwarded-Encrypted: i=1; AFNElJ9NOYfDMuw63TxDnXCZ5AtYGItjrGOHAonlUGooYcUzbWFpXXmgG6mZl5bNgtasK3txBZ1SMxH2vvBv8oc=@vger.kernel.org X-Gm-Message-State: AOJu0YwgoG9UXUkfaoRGAWr9fXeZXjFKwMo0GKP90OabOma2oEZwrULo bB0IyRq39l/ZbHXjs8uAh6eg2dx+QWaeCssOJkETLlkPFCcjDoslV52btJhvWcwKRZ0= X-Gm-Gg: AeBDievfEnlCDvLAx/LTZplSxNOeN/3CfCSCmEuTHy8l/w1r1YrDhfKQ0Gpw3pZfSHI FltFeu3qUfIL05abUYurHV/UamGRM+a7FJVcMdgYUrNrVFpxwMf+TCjDNkv6zRYE+7G5y5QZYml P4fSGgWzXm1ETa3Og5eLX91MdbfjduQtGoFWt73SJWo0ocsz107P6B4OVTRk10frN4BhkIvcql0 KYmvNiSktCBw8mUVQjxwnKlIQQn6aycicJA4JqDwhphZPHInm1sZ1PpLj3wV8ByTTGGotvCWo6v aWPjSKLCcCi6ibHimmHTJvwFqrHvPPclrHDW+KZs3HdrcegYDH/5zXTzfutnwwFbh9qC8PZnQKu 48A3GrK5ej3mZ1siFHVOftCnsDgUlIpZWxLNdt/McVempRH1o2zeUmIgcbIQuJzHKYLxUn3rdHk qtip2niqYhKT8XJoDZoQ== X-Received: by 2002:a05:6000:2503:b0:43e:b0f8:66f1 with SMTP id ffacd0b85a97d-43eb0f866f9mr6366546f8f.43.1776351279910; Thu, 16 Apr 2026 07:54:39 -0700 (PDT) Received: from localhost ([2a09:bac6:37a8:d2::15:40d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43ead3e00b3sm13211504f8f.27.2026.04.16.07.54.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 07:54:39 -0700 (PDT) Date: Thu, 16 Apr 2026 15:54:38 +0100 From: Matt Fleming To: Shakeel Butt Cc: Andrew Morton , Christoph Hellwig , Jens Axboe , Sergey Senozhatsky , Roman Gushchin , Minchan Kim , kernel-team@cloudflare.com, Matt Fleming , Johannes Weiner , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Qi Zheng , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim Message-ID: References: <20260410101550.2930139-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: On Wed, Apr 15, 2026 at 06:01:54PM -0700, Shakeel Butt wrote: > On Fri, Apr 10, 2026 at 11:15:49AM +0100, Matt Fleming wrote: > > > > @@ -4637,7 +4672,24 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order, > > !__cpuset_zone_allowed(zone, gfp_mask)) > > continue; > > > > - available = reclaimable = zone_reclaimable_pages(zone); > > + /* > > + * Only count reclaimable pages from an LRU type if reclaim > > + * actually made headway on that type in the last cycle. > > + * This prevents the allocator from looping endlessly on > > + * account of a large pool of pages that reclaim cannot make > > + * progress on, e.g. anonymous pages when the only swap is > > + * RAM-backed (zram). > > + */ > > + reclaimable = 0; > > + reclaimable_file = zone_reclaimable_file_pages(zone); > > + reclaimable_anon = zone_reclaimable_anon_pages(zone); > > Here we are getting the current reclaimable pages. > > > + > > + if (reclaim_progress_sufficient(progress->nr_file, reclaimable_file)) > > + reclaimable += reclaimable_file; > > + if (reclaim_progress_sufficient(progress->nr_anon, reclaimable_anon)) > > + reclaimable += reclaimable_anon; > > And here we are comparing the current reclaimable pages with last iteration. Is > this intentional to keep things simple? Yep, that was the intent. > > + > > + available = reclaimable; > > available += zone_page_state_snapshot(zone, NR_FREE_PAGES); > > > > Another heuristic we can play with is to also pass through the vmscan scan > count. If for couple of consecutive iterations, we continue to see low reclaim > efficiency, go for OOM. Also maybe compare the scan count with the watermark as > I expect we don't see much difference scan count for consecutive reclaim > iteration, so, it is a good representative of reclaimable memory. > > The reclaim efficiency heuristic should handle the swap-on-zram or > incomp-zswap-with-no-writeback. Treating scan count as proxy for reclaimable > memory should handle the overcommitted memory.min case. Nice. I'll take a look at this.