From: Byungchul Park <byungchul@sk.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: kernel_team@skhynix.com, akpm@linux-foundation.org,
ying.huang@intel.com, namit@vmware.com, xhao@linux.alibaba.com,
mgorman@techsingularity.net, hughd@google.com,
willy@infradead.org, david@redhat.com, peterz@infradead.org,
luto@kernel.org, dave.hansen@linux.intel.com
Subject: [RFC v2 0/6] Reduce TLB flushes under some specific conditions
Date: Thu, 17 Aug 2023 17:05:53 +0900 [thread overview]
Message-ID: <20230817080559.43200-1-byungchul@sk.com> (raw)
Hi,
While I'm working with CXL memory, I have been facing migraion 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").
However, it's only for ones using hinting fault. I thought it'd be much
better if we have a general mechanism to reduce # of TLB flushes that
we can apply to any type of migration. I tried it only for tiering
migration for now tho.
I'm suggesting a mechanism to reduce TLB flushes by keeping source and
destination of folios participated in the migrations until all TLB
flushes required are done, only if those folios are not mapped with
write permission PTE entries at all.
I saw the number of TLB full flush reduced over 50% and the performance
a little bit improved but not that big with the workload I tested with,
XSBench. However, I believe that it would help more with other ones or
any real ones. It'd be appreciated to tell me if I'm missing something.
Byungchul
---
Changes from RFC:
1. Fix a bug triggered when a destination folio at the previous
migration becomes a source folio at the next migration,
before the folio gets handled properly so that the folio can
play with another migration. There was inconsistency in the
folio's state. Fixed it.
2. Split the patch set into more pieces so that the folks can
review better. (Feedbacked by Nadav Amit)
3. Fix a wrong usage of barrier e.g. smp_mb__after_atomic().
(Feedbacked by Nadav Amit)
4. Tried to add sufficient comments to explain the patch set
better. (Feedbacked by Nadav Amit)
Byungchul Park (6):
mm/rmap: Recognize non-writable TLB entries during TLB batch flush
mm: Defer TLB flush by keeping both src and dst folios at migration
mm, migrc: Skip TLB flushes at the CPUs that already have been done
mm, migrc: Ajust __zone_watermark_ok() with the amount of pending
folios
mm, migrc: Add a sysctl knob to enable/disable MIGRC mechanism
mm, migrc: Implement internal allocator to minimize impact onto vm
arch/x86/include/asm/tlbflush.h | 9 +
arch/x86/mm/tlb.c | 67 ++++++
include/linux/mm.h | 30 +++
include/linux/mm_types.h | 47 ++++
include/linux/mm_types_task.h | 4 +-
include/linux/mmzone.h | 6 +
include/linux/sched.h | 5 +
init/Kconfig | 13 ++
mm/internal.h | 14 ++
mm/memory.c | 17 +-
mm/migrate.c | 381 +++++++++++++++++++++++++++++++-
mm/mm_init.c | 1 +
mm/page_alloc.c | 19 ++
mm/rmap.c | 133 ++++++++++-
14 files changed, 734 insertions(+), 12 deletions(-)
--
2.17.1
next reply other threads:[~2023-08-17 8:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 8:05 Byungchul Park [this message]
2023-08-17 8:05 ` [RFC v2 1/6] mm/rmap: Recognize non-writable TLB entries during TLB batch flush Byungchul Park
2023-08-17 8:05 ` [RFC v2 2/6] mm: Defer TLB flush by keeping both src and dst folios at migration Byungchul Park
2023-08-17 8:05 ` [RFC v2 3/6] mm, migrc: Skip TLB flushes at the CPUs that already have been done Byungchul Park
2023-08-17 8:05 ` [RFC v2 4/6] mm, migrc: Ajust __zone_watermark_ok() with the amount of pending folios Byungchul Park
2023-08-17 8:05 ` [RFC v2 5/6] mm, migrc: Add a sysctl knob to enable/disable MIGRC mechanism Byungchul Park
2023-08-17 8:05 ` [RFC v2 6/6] mm, migrc: Implement internal allocator to minimize impact onto vm 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=20230817080559.43200-1-byungchul@sk.com \
--to=byungchul@sk.com \
--cc=akpm@linux-foundation.org \
--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=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=willy@infradead.org \
--cc=xhao@linux.alibaba.com \
--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;
as well as URLs for NNTP newsgroup(s).