From: Byungchul Park <byungchul@sk.com>
To: "Huang, Ying" <ying.huang@intel.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
kernel_team@skhynix.com, akpm@linux-foundation.org,
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 v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90%
Date: Wed, 22 May 2024 23:15:55 +0900 [thread overview]
Message-ID: <20240522141555.GA34201@system.software.com> (raw)
In-Reply-To: <20240522102743.GA29930@system.software.com>
On Wed, May 22, 2024 at 07:27:44PM +0900, Byungchul Park wrote:
> On Wed, May 22, 2024 at 03:38:04PM +0800, Huang, Ying wrote:
> > Hi, Byungchul,
> >
> > Byungchul Park <byungchul@sk.com> writes:
> >
> > > On Mon, May 13, 2024 at 10:44:29AM +0900, Byungchul Park wrote:
> > >> On Sat, May 11, 2024 at 03:15:01PM +0800, Huang, Ying wrote:
> > >> > Byungchul Park <byungchul@sk.com> writes:
> > >> >
> > >> > > Hi everyone,
> > >> > >
> > >> > > While I'm working with a tiered memory system e.g. CXL memory, I have
> > >> > > been facing migration overhead esp. tlb shootdown on promotion or
> > >> > > demotion between different tiers. Yeah.. most tlb shootdowns on
> > >> > > migration through hinting fault can be avoided thanks to Huang Ying's
> > >> > > work, commit 4d4b6d66db ("mm,unmap: avoid flushing tlb in batch if PTE
> > >> > > is inaccessible"). See the following link for more information:
> > >> > >
> > >> > > https://lore.kernel.org/lkml/20231115025755.GA29979@system.software.com/
> > >> >
> > >> > And, I still have interest of the performance impact of commit
> > >> > 7e12beb8ca2a ("migrate_pages: batch flushing TLB"). In the email above,
> > >> > you said that the performance of v6.5-rc5 + 7e12beb8ca2a reverted has
> > >> > better performance than v6.5-rc5. Can you provide more details? For
> > >> > example, the number of TLB flushing IPI for two kernels?
> > >>
> > >> Okay. I will test and share the result with what you asked me now once
> > >> I get available for the test.
> > >
> > > I should admit that the test using qemu is so unstable. While using
> > > qemu for the test, kernel with 7e12beb8ca2a applied gave better results
> > > sometimes and worse ones sometimes. I should've used a bare metal from
> > > the beginning. Sorry for making you confused with the unstable result.
> > >
> > > Since I thought you asked me for the test with the same environment in
> > > the link above, I used qemu to reproduce the similar result but changed
> > > the number of threads for the test from 16 to 14 to get rid of noise
> > > that might be introduced by other than the intended test just in case.
> > >
> > > As expected, the stats are better with your work:
> > >
> > > ------------------------------------------
> > > v6.6-rc5 with 7e12beb8ca2a commit reverted
> > > ------------------------------------------
> > >
> > > 1) from output of XSBench
> > >
> > > Threads: 14
> > > Runtime: 1127.043 seconds
> > > Lookups: 1,700,000,000
> > > Lookups/s: 1,508,371
> > >
> > > 2) from /proc/vmstat
> > >
> > > numa_hit 15580171
> > > numa_miss 1034233
> > > numa_foreign 1034233
> > > numa_interleave 773
> > > numa_local 7927442
> > > numa_other 8686962
> > > numa_pte_updates 24068923
> > > numa_hint_faults 24061125
> > > numa_hint_faults_local 0
> > > numa_pages_migrated 7426480
> > > pgmigrate_success 15407375
> > > pgmigrate_fail 1849
> > > compact_migrate_scanned 4445414
> > > compact_daemon_migrate_scanned 4445414
> > > pgdemote_kswapd 7651061
> > > pgdemote_direct 0
> > > nr_tlb_remote_flush 8080092
> > > nr_tlb_remote_flush_received 109915713
> > > nr_tlb_local_flush_all 53800
> > > nr_tlb_local_flush_one 770466
> > >
> > > 3) from /proc/interrupts
> > >
> > > TLB: 8022927 7840769 123588 7837008 7835967 7839837
> > > 7838332 7839886 7837610 7837221 7834524 407260
> > > 7430090 7835696 7839081 7712568 TLB shootdowns
> > >
> > > 4) from 'perf stat -a'
> > >
> > > 222371217 itlb.itlb_flush
> > > 919832520 tlb_flush.dtlb_thread
> > > 372223809 tlb_flush.stlb_any
> > > 120210808042 dTLB-load-misses
> > > 979352769 dTLB-store-misses
> > > 3650767665 iTLB-load-misses
> > >
> > > -----------------------------------------
> > > v6.6-rc5 with 7e12beb8ca2a commit applied
> > > -----------------------------------------
> > >
> > > 1) from output of XSBench
> > >
> > > Threads: 14
> > > Runtime: 1105.521 seconds
> > > Lookups: 1,700,000,000
> > > Lookups/s: 1,537,737
> > >
> > > 2) from /proc/vmstat
> > >
> > > numa_hit 24148399
> > > numa_miss 797483
> > > numa_foreign 797483
> > > numa_interleave 772
> > > numa_local 12214575
> > > numa_other 12731307
> > > numa_pte_updates 24250278
> > > numa_hint_faults 24199756
> > > numa_hint_faults_local 0
> > > numa_pages_migrated 11476195
> > > pgmigrate_success 23634639
> > > pgmigrate_fail 1391
> > > compact_migrate_scanned 3760803
> > > compact_daemon_migrate_scanned 3760803
> > > pgdemote_kswapd 11932217
> > > pgdemote_direct 0
> > > nr_tlb_remote_flush 2151945
> > > nr_tlb_remote_flush_received 29672808
> > > nr_tlb_local_flush_all 124006
> > > nr_tlb_local_flush_one 741165
> > >
> > > 3) from /proc/interrupts
> > >
> > > TLB: 2130784 2120142 2117571 844962 2071766 114675
> > > 2117258 2119596 2116816 1205446 2119176 2119209
> > > 2116792 2118763 2118773 2117762 TLB shootdowns
> > >
> > > 4) from 'perf stat -a'
> > >
> > > 60851902 itlb.itlb_flush
> > > 334068491 tlb_flush.dtlb_thread
> > > 223732916 tlb_flush.stlb_any
> > > 120207083382 dTLB-load-misses
> > > 446823059 dTLB-store-misses
> > > 1926669373 iTLB-load-misses
> > >
> >
> > Thanks a lot for test results!
> >
> > >From your test results, the TLB shootdown IPI can be reduced effectively
> > with commit 7e12beb8ca2a. So that the benchmark score improved a
> > little.
> >
> > And, your changes will reduce the TLB shootdown IPI further, right? Do
>
> Yes, right. LUF(Lazy Unmap Flush) reduces TLB shootdown IPI further.
>
> > you have the number?
>
> You can find the number obtained from llama.cpp in this cover letter:
>
> https://lore.kernel.org/lkml/20240520021734.21527-1-byungchul@sk.com/
>
> If you meant the number from the same test above, XSBench + qemu, I will
> re-test with mm-unstable branch of mm tree and share the result shortly.
I retested the same test but based on a recent mm-unstable branch of mm
tree instead of v6.6-rc5. The result changed because of the different
base, from v6.6-rc5 to a recent mm-unstable branch of mm tree.
----------------------------------------------------
mm-unstable branch with 7e12beb8ca2a commit reverted
----------------------------------------------------
1) from output of XSBench
Threads: 14
Runtime: 1067.771 seconds
Lookups: 1,700,000,000
Lookups/s: 1,592,101
2) from /proc/vmstat
numa_hit 11502876
numa_miss 1130877
numa_foreign 1130877
numa_interleave 115
numa_local 5879006
numa_other 6754747
numa_pte_updates 19390661
numa_hint_faults 19319467
numa_hint_faults_local 0
numa_pages_migrated 5472749
pgmigrate_success 11593079
pgmigrate_fail 549666
compact_migrate_scanned 5408404
compact_daemon_migrate_scanned 5408404
pgdemote_kswapd 5610705
pgdemote_direct 0
nr_tlb_remote_flush 6200106
nr_tlb_remote_flush_received 84362539
nr_tlb_local_flush_all 39202
nr_tlb_local_flush_one 760046
3) from /proc/interrupts
TLB: 3812782 3840646 4806989 5235846 5127512 5048603
6012100 6022642 5088907 5212207 4076329 6014857
6017060 6014964 6009362 6018368 TLB shootdowns
4) from 'perf stat -a'
180449546 itlb.itlb_flush
768913454 tlb_flush.dtlb_thread
304745973 tlb_flush.stlb_any
119589742349 dTLB-load-misses
826525376 dTLB-store-misses
2950724801 iTLB-load-misses
---------------------------------------------------
mm-unstable branch with 7e12beb8ca2a commit applied
---------------------------------------------------
1) from output of XSBench
Threads: 14
Runtime: 1043.972 seconds
Lookups: 1,700,000,000
Lookups/s: 1,628,395
2) from /proc/vmstat
numa_hit 16865880
numa_miss 1129958
numa_foreign 1129958
numa_interleave 115
numa_local 8565072
numa_other 9430766
numa_pte_updates 19240583
numa_hint_faults 19239948
numa_hint_faults_local 0
numa_pages_migrated 8159078
pgmigrate_success 17000781
pgmigrate_fail 1410437
compact_migrate_scanned 5075605
compact_daemon_migrate_scanned 5075605
pgdemote_kswapd 8297460
pgdemote_direct 0
nr_tlb_remote_flush 1516807
nr_tlb_remote_flush_received 20938785
nr_tlb_local_flush_all 95801
nr_tlb_local_flush_one 740597
3) from /proc/interrupts
TLB: 927080 567584 840684 1484285 1495859 1408641
1496227 1493909 1359465 1227623 1265431 1496361
1392337 1489451 1495799 1494700 TLB shootdowns
4) from 'perf stat -a'
43564429 itlb.itlb_flush
272921880 tlb_flush.dtlb_thread
175495467 tlb_flush.stlb_any
119602211976 dTLB-load-misses
355190881 dTLB-store-misses
1539926469 iTLB-load-misses
---------------------------------------------------------
mm-unstable branch with 7e12beb8ca2a commit applied + LUF
---------------------------------------------------------
1) from output of XSBench
Threads: 14
Runtime: 1033.973 seconds
Lookups: 1,700,000,000
Lookups/s: 1,644,144
2) from /proc/vmstat
numa_hit 18617127
numa_miss 1075467
numa_foreign 1075467
numa_interleave 115
numa_local 9440134
numa_other 10252460
numa_pte_updates 19473883
numa_hint_faults 19470143
numa_hint_faults_local 0
numa_pages_migrated 8978959
pgmigrate_success 18675500
pgmigrate_fail 1577460
compact_migrate_scanned 5465414
compact_daemon_migrate_scanned 5465414
pgdemote_kswapd 9172431
pgdemote_direct 0
nr_tlb_remote_flush 85818
nr_tlb_remote_flush_received 1036316
nr_tlb_local_flush_all 34674
nr_tlb_local_flush_one 740870
3) from /proc/interrupts
TLB: 55328 31254 44449 72887 73407 73775
73353 73658 35802 68184 70998 73504
74072 64700 73718 73862 TLB shootdowns
4) from 'perf stat -a'
2054390 itlb.itlb_flush
150073902 tlb_flush.dtlb_thread
135630767 tlb_flush.stlb_any
117880065362 dTLB-load-misses
217521760 dTLB-store-misses
908338035 iTLB-load-misses
---
The result looks incredible. You can also see the result if you try to
test a workload triggering reclaim or migration with LUF.
Byungchul
next prev parent reply other threads:[~2024-05-22 14:16 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 6:51 [PATCH v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Byungchul Park
2024-05-10 6:51 ` [PATCH v10 01/12] x86/tlb: add APIs manipulating tlb batch's arch data Byungchul Park
2024-05-10 6:51 ` [PATCH v10 02/12] arm64: tlbflush: " Byungchul Park
2024-05-10 6:51 ` [PATCH v10 03/12] riscv, tlb: " Byungchul Park
2024-05-10 6:51 ` [PATCH v10 04/12] x86/tlb, riscv/tlb, mm/rmap: separate arch_tlbbatch_clear() out of arch_tlbbatch_flush() Byungchul Park
2024-05-10 6:51 ` [PATCH v10 05/12] mm: buddy: make room for a new variable, ugen, in struct page Byungchul Park
2024-05-10 6:52 ` [PATCH v10 06/12] mm: add folio_put_ugen() to deliver unmap generation number to pcp or buddy Byungchul Park
2024-05-10 6:52 ` [PATCH v10 07/12] mm: add a parameter, unmap generation number, to free_unref_folios() Byungchul Park
2024-05-10 6:52 ` [PATCH v10 08/12] mm/rmap: recognize read-only tlb entries during batched tlb flush Byungchul Park
2024-05-10 6:52 ` [PATCH v10 09/12] mm: implement LUF(Lazy Unmap Flush) defering tlb flush when folios get unmapped Byungchul Park
2024-05-10 6:52 ` [PATCH v10 10/12] mm: separate move/undo parts from migrate_pages_batch() Byungchul Park
2024-05-10 6:52 ` [PATCH v10 11/12] mm, migrate: apply luf mechanism to unmapping during migration Byungchul Park
2024-05-10 6:52 ` [PATCH v10 12/12] mm, vmscan: apply luf mechanism to unmapping during folio reclaim Byungchul Park
2024-05-11 6:54 ` [PATCH v10 00/12] LUF(Lazy Unmap Flush) reducing tlb numbers over 90% Huang, Ying
2024-05-13 1:41 ` Byungchul Park
2024-05-11 7:15 ` Huang, Ying
2024-05-13 1:44 ` Byungchul Park
2024-05-22 2:16 ` Byungchul Park
2024-05-22 7:38 ` Huang, Ying
2024-05-22 10:27 ` Byungchul Park
2024-05-22 14:15 ` Byungchul Park [this message]
2024-05-24 17:16 ` Dave Hansen
2024-05-27 1:57 ` Byungchul Park
2024-05-27 2:43 ` Dave Hansen
2024-05-27 3:46 ` Byungchul Park
2024-05-27 4:19 ` Byungchul Park
2024-05-27 4:25 ` Byungchul Park
2024-05-27 22:58 ` Byungchul Park
2024-05-29 2:16 ` Huang, Ying
2024-05-30 1:02 ` Byungchul Park
2024-05-27 3:10 ` Huang, Ying
2024-05-27 3:56 ` Byungchul Park
2024-05-28 15:14 ` Dave Hansen
2024-05-29 5:00 ` Byungchul Park
2024-05-29 16:41 ` Dave Hansen
2024-05-30 0:50 ` Byungchul Park
2024-05-30 0:59 ` Byungchul Park
2024-05-30 1:11 ` Huang, Ying
2024-05-30 1:33 ` Byungchul Park
2024-05-30 7:18 ` Byungchul Park
2024-05-30 8:24 ` Huang, Ying
2024-05-30 8:41 ` Byungchul Park
2024-05-30 13:50 ` Dave Hansen
2024-05-31 2:06 ` Byungchul Park
2024-05-30 9:33 ` Byungchul Park
2024-05-31 1:45 ` Huang, Ying
2024-05-31 2:20 ` Byungchul Park
2024-05-28 8:41 ` David Hildenbrand
2024-05-29 4:39 ` 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=20240522141555.GA34201@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.