Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <baoquan.he@linux.dev>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: "Barry Song (Xiaomi)" <baohua@kernel.org>,
	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,
	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: Fri, 12 Jun 2026 09:08:09 +0800	[thread overview]
Message-ID: <aitb-XwJ0gRiOqPW@MiWiFi-R3L-srv> (raw)
In-Reply-To: <air7FCRQneIPiJ5l@linux.dev>

On 06/11/26 at 11:17am, Shakeel Butt wrote:
> On Thu, Jun 11, 2026 at 11:09:43AM -0700, Shakeel Butt 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?
> > 
> > I wonder if that data can motivate to introduce lru_add_drain_folio(folio) which
> > only drains if the given folio is in the local lru_add cache.
> 
> Actually if we can peek into lru_add cache and folio_ref_count(folio) is exactly
> equal to (2 + folio_test_swapcache(folio)) and folio is not on LRU then we can
> just reuse folio if it is in lru_add cache without draining, right?

Sounds more reasonable if we can only touch the wanted folio if it
exists in pvec. Believe it can improve efficiency more than the
current patch.

> 
> > 
> > >  		/*
> > >  		 * We cannot easily detect+handle references from
> > >  		 * remote LRU caches or references to LRU folios.
> > >  		 */
> > >  		lru_add_drain();
> > > +	}
> > >  	if (folio_ref_count(folio) > 1 + folio_test_swapcache(folio))
> > >  		return false;
> > >  	if (!folio_trylock(folio))
> > > -- 
> > > 2.39.3 (Apple Git-146)
> > > 


  reply	other threads:[~2026-06-12  1:08 UTC|newest]

Thread overview: 15+ 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 [this message]
2026-06-12  1:57         ` Barry Song
2026-06-12  3:40           ` Baoquan He
2026-06-12  1:35       ` Barry Song
2026-06-12  3:41   ` Baoquan He
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-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

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=aitb-XwJ0gRiOqPW@MiWiFi-R3L-srv \
    --to=baoquan.he@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --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=shakeel.butt@linux.dev \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox