From: "Garg, Shivank" <shivankg@amd.com>
To: "baohua@kernel.org" <baohua@kernel.org>
Cc: "hughd@google.com" <hughd@google.com>,
"npache@redhat.com" <npache@redhat.com>,
"rppt@kernel.org" <rppt@kernel.org>,
"vbabka@kernel.org" <vbabka@kernel.org>,
"david@kernel.org" <david@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"dev.jain@arm.com" <dev.jain@arm.com>,
"surenb@google.com" <surenb@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"usama.arif@linux.dev" <usama.arif@linux.dev>,
"ackerleytng@google.com" <ackerleytng@google.com>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"ryan.roberts@arm.com" <ryan.roberts@arm.com>,
"liam@infradead.org" <liam@infradead.org>,
"baolin.wang@linux.alibaba.com" <baolin.wang@linux.alibaba.com>,
"joannelkoong@gmail.com" <joannelkoong@gmail.com>,
"mhocko@suse.com" <mhocko@suse.com>,
"ljs@kernel.org" <ljs@kernel.org>,
"lance.yang@linux.dev" <lance.yang@linux.dev>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>
Subject: Re: [RFC PATCH v3 0/4] mm: enable lru cache for smaller large folios
Date: Sat, 12 Sep 2026 09:58:48 +0000 [thread overview]
Message-ID: <966a7f6a4cd941bdab7161ad28fa5f8578225518.camel@amd.com> (raw)
In-Reply-To: <CAGsJ_4yjHqSFtmHrRKgE1JrJpQKw5oBs1cuX1_mQ_r0wKdMdYw@mail.gmail.com>
On Sat, 2026-09-12 at 05:20 +0800, Barry Song wrote:
> On Fri, Sep 11, 2026 at 11:39 PM Garg, Shivank <shivankg@amd.com> wrote:
> [...]
> >
> > Thanks for this series.
> > I tested this against a Graph500 regression with 16K mTHP.
> > The series removes the regression and reduces folio_lruvec_lock_irqsave contention to approximately the 4K rate.
> >
> >
> > Tested-by: Shivank Garg <shivankg@amd.com>
> >
>
> Thanks very much, Shivank. I’m very happy to see that
> mTHP LRUCACHE not only resolves your regression but also
> improves the performance of your case.
>
> As discussed with David, this series will be respun after Hugh’s
> work[1] is merged.
>
> In the meantime, I’d really appreciate it if you could test an
> updated version that I haven’t sent out before:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git/log/?h=mthp_lrucache
>
> It includes some modifications based on Sashiko’s review comments
> on the version you tested. I’d like to know whether it still provides
> the same performance gains you saw with that version.
>
> [1] https://lore.kernel.org/linux-mm/e28f9a94-4339-f8ac-8301-6be3c9b5b7ce@google.com/
>
I tested this branch.
Base: 4b65683fd ("mm/swap, PM: hibernate: atomically replace
hibernation pin")
Patched (Base+series): 5dfdf87ee (branch tip, the 4 lru_cache patches)
Base Patched reduction
4K 839281 2.30 m 842435 2.91 m
mTHP-16K 7032797 28.79 m 839301 4.53 m 8.4x / 6.4x
mTHP-64K 267948 1.19 s 36073 93.48 ms 7.4x / 12.7x
Numbers are almost unchanged, except some run-to-run variations.
Thanks
Shivank
> >
> > System and Workload
> > ===================
> >
> > AMD EPYC Zen 5 System, 2 sockets, 160 cores/socket,
> > SMT on -> 320 cores / 640 threads
> > 2 NUMA nodes, ~512 GB/node
> > node 0 CPUs: 0-159,320-479
> >
> > Base: v7.3-rc2+ (50d05c7c76c9)
> > Runtime: performance governor, preempt=full (lazy)
> >
> > Workload: Graph500, Scale 27, edgefactor 16
> > Metric: median_time in ms (lower is better)
> >
> > Bind to node 0 with numactl -C 0-159,320-479 -m 0
> >
> >
> > Performance
> > ===========
> >
> > Base Patched delta
> > 4K 109.60 109.11 -0.4%
> > mTHP-16K 144.10 99.00 -31.3%
> > mTHP-64K 104.75 104.25 -0.5%
> >
> > mTHP-16K was ~31% slower than THP-never, due to lock contentions.
> > With your series, mTHP-16 performs ~9% faster than THP-never.
> >
> >
> > The dominant folio_lruvec_lock_irqsave entries were:
> >
> > Base Patched
> > contended wait contended wait
> > 4K 834603 2.41 m 844193 2.61 m
> > mTHP-16K 7008834 28.88 m 840695 4.87 m
> > mTHP-64K 188144 752 ms 40874 93.46 ms
> >
> >
>
prev parent reply other threads:[~2026-09-12 9:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 22:59 Barry Song (Xiaomi)
2026-08-18 22:59 ` [RFC PATCH v3 1/4] mm: allow smaller large folios to use lru_cache Barry Song (Xiaomi)
2026-08-19 4:34 ` Barry Song
2026-08-18 22:59 ` [RFC PATCH v3 2/4] mm: improve large folio reuse for LRU-cached folios Barry Song (Xiaomi)
2026-08-18 22:59 ` [RFC PATCH v3 3/4] mm: drain LRU cache if necessary for splitting large folios Barry Song (Xiaomi)
2026-08-20 10:14 ` Barry Song
2026-08-18 22:59 ` [RFC PATCH v3 4/4] mm: batch lru_cache draining in deferred_split_scan Barry Song (Xiaomi)
2026-08-19 3:02 ` [RFC PATCH v3 0/4] mm: enable lru cache for smaller large folios Lance Yang
2026-08-19 4:38 ` Barry Song
2026-08-20 18:23 ` David Hildenbrand (Arm)
2026-08-20 20:18 ` Barry Song
2026-08-20 20:22 ` Barry Song
2026-08-21 14:18 ` David Hildenbrand (Arm)
2026-08-21 18:53 ` Barry Song
2026-09-11 15:38 ` Garg, Shivank
2026-09-11 21:20 ` Barry Song
2026-09-12 9:58 ` Garg, Shivank [this message]
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=966a7f6a4cd941bdab7161ad28fa5f8578225518.camel@amd.com \
--to=shivankg@amd.com \
--cc=ackerleytng@google.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=joannelkoong@gmail.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=usama.arif@linux.dev \
--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
all inboxes | Powered by JetHome®