From: Byungchul Park <byungchul@sk.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel_team@skhynix.com, ying.huang@intel.com,
vernhao@tencent.com, mgorman@techsingularity.net,
hughd@google.com, willy@infradead.org, david@redhat.com,
peterz@infradead.org, luto@kernel.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
rjgolo@gmail.com
Subject: Re: [PATCH v9 rebase on mm-unstable 0/8] Reduce tlb and interrupt numbers over 90% by improving folio migration
Date: Fri, 19 Apr 2024 15:02:34 +0900 [thread overview]
Message-ID: <20240419060234.GA48027@system.software.com> (raw)
In-Reply-To: <20240418131757.cd05a8e7c7e66b3e90508c11@linux-foundation.org>
On Thu, Apr 18, 2024 at 01:17:57PM -0700, Andrew Morton wrote:
> On Thu, 18 Apr 2024 15:15:28 +0900 Byungchul Park <byungchul@sk.com> wrote:
>
> > $ time XSBench -t 16 -p 50000000
> >
> > BEFORE
> > ------
> > Threads: 16
> > Runtime: 968.783 seconds
> > Lookups: 1,700,000,000
> > Lookups/s: 1,754,778
> >
> > 15208.91s user 141.44s system 1564% cpu 16:20.98 total
> >
> > AFTER
> > -----
> > Threads: 16
> > Runtime: 913.210 seconds
> > Lookups: 1,700,000,000
> > Lookups/s: 1,861,565
> >
> > 14351.69s user 138.23s system 1565% cpu 15:25.47 total
>
> Well that's nice. What exactly is XSBench doing in this situation?
As far as I know, it's frequently and continuously accessing annon areas
with addresses ranged within 6GB, by multi threads. Thus, it triggers a
lot of promotions by hinting fault of numa balancing tiering and a lot
of demotions by kswapd as well, resulting in a ton of tlb flushes.
All I need is a system suffering from memory reclaim or any type of
folio migration since migrc mechanism is one for mitigating the overhead
of folio migration. To see the benefits of migrc, it doesn't have to be
XSBench but any workload suffering from reclaim.
> What sort of improvements can we expect to see in useful workloads?
Increase throughput(= runtime reduction of each work in the system).
1. Because migrc removes the CPU time that would've been spent in IPI
handler due to tlb shootdown, by skipping a lot of tlb shootdowns.
2. Becasue migrc reduces tlb misses so as to utilize tlb cache better,
by skipping a lof of tlb flushes.
Besides, I expect overall scheduler latencies can be enhanced, the worst
latencies measured using some tracters of ftrace showed no change though.
> I see it no longer consumes an additional page flag, good.
>
> The patches show no evidence of review activity and I'm not seeing much
> on the mailing list (patchset title was changed. Previous title
> "Reduce TLB flushes under some specific conditions"). Perhaps a better
I changed the title because it was supposed to work with only numa
balancing tiering like promotion and demotion but, for now, migrc works
with any type of folio migration. Thus, I can tell migrc demonstrates
its benefits as long as a system is under the control of reclaim and
folio migration.
Byungchul
> description of the overall benefit to our users would help to motivate
> reviewers.
next prev parent reply other threads:[~2024-04-19 6:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 6:15 [PATCH v9 rebase on mm-unstable 0/8] Reduce tlb and interrupt numbers over 90% by improving folio migration Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 1/8] x86/tlb: add APIs manipulating tlb batch's arch data Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 2/8] arm64: tlbflush: " Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 3/8] mm/rmap: recognize read-only tlb entries during batched tlb flush Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 4/8] x86/tlb, mm/rmap: separate arch_tlbbatch_clear() out of arch_tlbbatch_flush() Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 5/8] mm: separate move/undo parts from migrate_pages_batch() Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 6/8] mm: buddy: make room for a new variable, mgen, in struct page Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 7/8] mm: add folio_put_mgen() to deliver migrc's generation number to pcp or buddy Byungchul Park
2024-04-18 6:15 ` [PATCH v9 rebase on mm-unstable 8/8] mm: defer tlb flush until the source folios at migration actually get used Byungchul Park
2024-04-18 20:17 ` [PATCH v9 rebase on mm-unstable 0/8] Reduce tlb and interrupt numbers over 90% by improving folio migration Andrew Morton
2024-04-19 6:02 ` Byungchul Park [this message]
2024-04-19 6:06 ` Huang, Ying
2024-04-19 6:21 ` Byungchul Park
2024-05-09 7:42 ` Byungchul Park
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=20240419060234.GA48027@system.software.com \
--to=byungchul@sk.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=kernel_team@skhynix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rjgolo@gmail.com \
--cc=tglx@linutronix.de \
--cc=vernhao@tencent.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.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