From: Shakeel Butt <shakeel.butt@linux.dev>
To: Barry Song <baohua@kernel.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, david@kernel.org, ljs@kernel.org,
liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, chrisl@kernel.org,
kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,
baoquan.he@linux.dev, youngjun.park@lge.com,
jp.kobryn@linux.dev, usama.arif@linux.dev
Subject: Re: [RFC PATCH 1/3] mm: avoid unnecessary lru drain for wp_can_reuse_anon_folio()
Date: Wed, 17 Jun 2026 08:08:35 -0700 [thread overview]
Message-ID: <ajK4N2zK3sPZFQuf@linux.dev> (raw)
In-Reply-To: <CAGsJ_4yCeAmpfo_8ef4MrRyRD_UtV-xGm6F4GpSjvLVPQsbiEg@mail.gmail.com>
On Fri, Jun 12, 2026 at 12:48:19PM +0800, Barry Song wrote:
> On Fri, Jun 12, 2026 at 2:10 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > On Thu, Jun 11, 2026 at 06:51:22PM +0800, Barry Song (Xiaomi) wrote:
> > > We always unconditionally drain the LRU before retrying anon folio
> > > reuse in wp_can_reuse_anon_folio(). Instead, assume !LRU anon folios
> > > are in lru_cache, and use the refcount to avoid many unnecessary LRU
> > > drains.
> > >
> > > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > > ---
> > > mm/memory.c | 8 +++++++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 56be920c56d7..487a34377a7b 100644
> > > --- a/mm/memory.c
> > > +++ b/mm/memory.c
> > > @@ -4193,12 +4193,18 @@ static bool wp_can_reuse_anon_folio(struct folio *folio,
> > > */
> > > if (folio_test_ksm(folio) || folio_ref_count(folio) > 3)
> > > return false;
> > > - if (!folio_test_lru(folio))
> > > + if (!folio_test_lru(folio)) {
> > > + /*
> > > + * Assume folio is on lru_cache and holds a cache reference.
> > > + */
> > > + if (folio_ref_count(folio) > 2 + folio_test_swapcache(folio))
> > > + return false;
> >
> > In your experiments, how much amount of drains were reduced due to this specific
> > check?
>
> This is a very good question. I booted the system into Ubuntu, and after
> boot completed I observed:
>
> wp_reuse_skipped_drain: 5542
> do_swap_skipped_drain: 0
>
> Then I built the kernel in a 1GB memcg using zRAM swap, and observed:
>
> wp_reuse_skipped_drain: 25017
> do_swap_skipped_drain: 43595
>
> So in summary, even without swap-in we can save a significant number of
> drains in wp_can_reuse_anon_folio(). With heavy swap-in workloads, most
> of the savings come from avoiding drains in do_swap_page(), while we
> still see a substantial number of skipped drains in wp_can_reuse_anon_folio().
Thanks and this is very good info. Add this in the commit message when you send
the non-RFC version.
next prev parent reply other threads:[~2026-06-17 15:08 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 10:51 [RFC PATCH 0/3] mm: drop redundant lru_add_drain in anon folio reuse paths Barry Song (Xiaomi)
2026-06-11 10:51 ` [RFC PATCH 1/3] mm: avoid unnecessary lru drain for wp_can_reuse_anon_folio() Barry Song (Xiaomi)
2026-06-11 18:09 ` Shakeel Butt
2026-06-11 18:17 ` Shakeel Butt
2026-06-12 1:08 ` Baoquan He
2026-06-12 1:57 ` Barry Song
2026-06-12 3:40 ` Baoquan He
2026-06-12 1:35 ` Barry Song
2026-06-17 15:16 ` Shakeel Butt
2026-06-12 4:48 ` Barry Song
2026-06-17 15:08 ` Shakeel Butt [this message]
2026-06-12 3:41 ` Baoquan He
2026-06-17 15:17 ` Shakeel Butt
2026-06-11 10:51 ` [RFC PATCH 2/3] mm: drop stale folio_ref_count()==1 check in do_swap_page reuse logic Barry Song (Xiaomi)
2026-06-11 18:12 ` Shakeel Butt
2026-06-12 1:18 ` Baoquan He
2026-06-17 3:18 ` Kairui Song
2026-06-17 13:51 ` Usama Arif
2026-06-11 10:51 ` [RFC PATCH 3/3] mm: entirely remove lru_add_drain in do_swap_page Barry Song (Xiaomi)
2026-06-11 18:40 ` Shakeel Butt
2026-06-12 1:39 ` Baoquan He
2026-06-17 5:37 ` Kairui Song
2026-06-17 9:55 ` Barry Song
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=ajK4N2zK3sPZFQuf@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=jp.kobryn@linux.dev \
--cc=kasong@tencent.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nphamcs@gmail.com \
--cc=rppt@kernel.org \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=youngjun.park@lge.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.