From: Pedro Falcato <pfalcato@suse.de>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Matt Fleming <matt@readmodwrite.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Jens Axboe <axboe@kernel.dk>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Minchan Kim <minchan@kernel.org>,
kernel-team@cloudflare.com,
Matt Fleming <mfleming@cloudflare.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <bhe@redhat.com>,
Barry Song <baohua@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>, Zi Yan <ziy@nvidia.com>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
David Hildenbrand <david@kernel.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Lorenzo Stoakes <ljs@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim
Date: Fri, 17 Apr 2026 11:35:04 +0100 [thread overview]
Message-ID: <sfyuribxce5qf7dvteztzfmlr5jvsjosg2rggjkjthcnlxeksv@jvadwjrg2nuo> (raw)
In-Reply-To: <aeFYrV78Q19c-RnB@linux.dev>
On Thu, Apr 16, 2026 at 02:49:28PM -0700, Shakeel Butt wrote:
> On Thu, Apr 16, 2026 at 03:51:04PM +0100, Matt Fleming wrote:
> > On Wed, Apr 15, 2026 at 03:57:25PM +0100, Pedro Falcato wrote:
> [...]
> >
> > > My theory (from merely reading the patch, maybe I missed something) is that
> > > a pathological case for this is a lot of folios added to the LRU in a row,
> > > that are set referenced (or dirty). Say SWAP_CLUSTER_MAX * MAX_RECLAIM_RETRIES
> > > - it will simply OOM too early.
> >
> > OK yeah I think I see the problem now: this heuristic applies the
> > threshold against all reclaimable pages but that falls apart when doing
> > SWAP_CLUSTER_MAX chunks of reclaim.
>
> I am not sure I understand the pathological case. Yes SWAP_CLUSTER_MAX is
> requested amount of pages to reclaim but the kernel can potentially scan full
> memory twice to reclaim that much amount. Though those reclaimed pages can get
> stolen but that can still happen today before this patch.
I see, yes, you are totally correct. Had a look at the vmscan code again and just
realized I had missed some details.
Matt, please disregard :)
--
Pedro
next prev parent reply other threads:[~2026-04-17 10:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 10:15 Matt Fleming
2026-04-13 15:38 ` Vlastimil Babka (SUSE)
2026-04-15 9:11 ` Matt Fleming
2026-04-15 14:57 ` Pedro Falcato
2026-04-16 14:51 ` Matt Fleming
2026-04-16 21:49 ` Shakeel Butt
2026-04-17 10:35 ` Pedro Falcato [this message]
2026-04-16 1:01 ` Shakeel Butt
2026-04-16 14:54 ` Matt Fleming
2026-04-16 1:44 ` Barry Song
2026-04-16 21:58 ` Shakeel Butt
-- strict thread matches above, loose matches on Subject: below --
2026-03-03 11:53 [RFC PATCH 0/1] mm: Reduce direct reclaim stalls with RAM-backed swap Matt Fleming
2026-04-10 9:41 ` [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim Matt Fleming
2026-04-10 10:13 ` Matt Fleming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sfyuribxce5qf7dvteztzfmlr5jvsjosg2rggjkjthcnlxeksv@jvadwjrg2nuo \
--to=pfalcato@suse.de \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=jackmanb@google.com \
--cc=kasong@tencent.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matt@readmodwrite.com \
--cc=mfleming@cloudflare.com \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=nphamcs@gmail.com \
--cc=roman.gushchin@linux.dev \
--cc=senozhatsky@chromium.org \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox