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
next prev parent reply other threads:[~2026-07-29 22:26 UTC|newest]
Thread overview: 8+ 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-30 9:28 ` David Hildenbrand (Arm)
2026-07-30 11:28 ` Zi Yan
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