Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: david@kernel.org
Cc: akpm@linux-foundation.org, baohua@kernel.org,
	baolin.wang@linux.alibaba.com, dev.jain@arm.com,
	lance.yang@linux.dev, liam@infradead.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org,
	mhocko@suse.com, npache@redhat.com, rppt@kernel.org,
	ryan.roberts@arm.com, surenb@google.com, vbabka@kernel.org,
	ziy@nvidia.com
Subject: Re: [RFC PATCH v2 1/2] mm: allow smaller large folios to use lru_cache
Date: Thu, 30 Jul 2026 06:26:51 +0800	[thread overview]
Message-ID: <20260729222651.31321-1-baohua@kernel.org> (raw)
In-Reply-To: <229c3079-8fde-41b4-9d6c-f0e34f780555@kernel.org>

On Wed, Jul 29, 2026 at 8:13 PM David Hildenbrand (Arm) <david@kernel.org> wrote:
[...]
> > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > index 8d19be675baf..9c5f7a11c7b0 100644
> > --- a/include/linux/swap.h
> > +++ b/include/linux/swap.h
> > @@ -316,9 +316,9 @@ static inline bool folio_may_be_lru_cached(struct folio *folio)
> >       /*
> >        * Holding PMD-sized folios in per-CPU LRU cache unbalances accounting.
> >        * Holding small numbers of low-order mTHP folios in per-CPU LRU cache
> > -      * will be sensible, but nobody has implemented and tested that yet.
> > +      * will be sensible.
> >        */
> > -     return !folio_test_large(folio);
> > +     return folio_order(folio) < PAGE_ALLOC_COSTLY_ORDER;
> >  }
> >
> >  extern atomic_t lru_disable_count;
>
> Sashiko rightfully raises that split_folio() can now fail more easily.
>
> So we might want to proactively drain (earlier?) on some more of the split paths.

Yes, this is a pain. I haven't tested it, but perhaps a
conceptual model could be something like this?

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 04e8a6b55343..fcd449dec96b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -4069,6 +4069,8 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 	struct folio *new_folio, *next;
 	int nr_shmem_dropped = 0;
 	enum ttu_flags ttu_flags = 0;
+	bool maybe_in_lru_cache;
+	int expected_ref_count;
 	int ret;
 	pgoff_t end = 0;
 
@@ -4154,7 +4156,15 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
 	 * Racy check if we can split the page, before unmap_folio() will
 	 * split PMDs
 	 */
-	if (folio_expected_ref_count(folio) != folio_ref_count(folio) - 1) {
+	maybe_in_lru_cache = folio_may_be_lru_cached(folio) && !folio_test_lru(folio);
+	expected_ref_count = folio_expected_ref_count(folio);
+	if (expected_ref_count + maybe_in_lru_cache < folio_ref_count(folio) - 1) {
+		ret = -EAGAIN;
+		goto out_unlock;
+	}
+	if (maybe_in_lru_cache)
+		lru_add_drain_all();
+	if (expected_ref_count != folio_ref_count(folio) - 1) {
 		ret = -EAGAIN;
 		goto out_unlock;
 	}

Best Regards
Barry


  reply	other threads:[~2026-07-29 22:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  8:15 [RFC PATCH v2 0/2] mm: enable lru cache for smaller large folios Barry Song (Xiaomi)
2026-07-09  8:15 ` [RFC PATCH v2 1/2] mm: allow smaller large folios to use lru_cache Barry Song (Xiaomi)
2026-07-29 12:13   ` David Hildenbrand (Arm)
2026-07-29 22:26     ` Barry Song (Xiaomi) [this message]
2026-07-09  8:15 ` [RFC PATCH v2 2/2] mm: improve large folio reuse for LRU-cached folios Barry Song (Xiaomi)
2026-07-29 12:11   ` David Hildenbrand (Arm)

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=20260729222651.31321-1-baohua@kernel.org \
    --to=baohua@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=npache@redhat.com \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --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