From: Alexander Gordeev <agordeev@linux.ibm.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>,
David Hildenbrand <david@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/6] s390/mm: Batch PTE updates in lazy MMU mode
Date: Wed, 15 Apr 2026 17:01:18 +0200 [thread overview]
Message-ID: <cover.1776264097.git.agordeev@linux.ibm.com> (raw)
Hi All!
This is v2 of the batched PTE updates in lazy MMU mode rework.
Changes since v1:
- lazy_mmu_mode_enable_pte() renamed to lazy_mmu_mode_enable_for_pte_range()
- lazy_mmu_mode_enable_for_pte_range() semantics clarified
- some sashiko comments addressed [1] including one bug fix
- patches 2-4 added
Patches 3-6 is the actual s390 rework, while patches 1,2 are a prerequisite
that affects the generic code.
Patch 6 needs to be mereged in patch 5 if deemed useful.
This series addresses an s390-specific aspect of how page table entries
are modified. In many cases, changing a valid PTE (for example, setting
or clearing a hardware bit) requires issuing an Invalidate Page Table
Entry (IPTE) instruction beforehand.
A disadvantage of the IPTE instruction is that it may initiate a
machine-wide quiesce state. This state acts as an expensive global
hardware lock and should be avoided whenever possible.
Currently, IPTE is invoked for each individual PTE update in most code
paths. However, the instruction itself supports invalidating multiple
PTEs at once, covering up to 256 entries. Using this capability can
significantly reduce the number of quiesce events, with a positive
impact on overall system performance. At present, this feature is not
utilized.
An effort was therefore made to identify kernel code paths that update
large numbers of consecutive PTEs. Such updates can be batched and
handled by a single IPTE invocation, leveraging the hardware support
described above.
A natural candidate for this optimization is page-table walkers that
change attributes of memory ranges and thus modify contiguous ranges
of PTEs. Many memory-management system calls enter lazy MMU mode while
updating such ranges.
This lazy MMU mode can be leveraged to build on the already existing
infrastructure and implement a software-level lazy MMU mechanism,
allowing expensive PTE invalidations on s390 to be batched.
1. https://sashiko.dev/#/patchset/cover.1774420056.git.agordeev%40linux.ibm.com
Thanks!
Alexander Gordeev (6):
mm: Make lazy MMU mode context-aware
mm/pgtable: Fix bogus comment to clear_not_present_full_ptes()
s390/mm: Complete ptep_get() conversion
s390/mm: Make PTC and UV call order consistent
s390/mm: Batch PTE updates in lazy MMU mode
s390/mm: Allow lazy MMU mode disabling
arch/s390/Kconfig | 11 +
arch/s390/boot/vmem.c | 32 +--
arch/s390/include/asm/hugetlb.h | 2 +-
arch/s390/include/asm/pgtable.h | 258 ++++++++++++++++----
arch/s390/mm/Makefile | 1 +
arch/s390/mm/hugetlbpage.c | 12 +-
arch/s390/mm/ipte_batch.c | 400 ++++++++++++++++++++++++++++++++
arch/s390/mm/pageattr.c | 42 ++--
arch/s390/mm/pgtable.c | 8 +-
arch/s390/mm/vmem.c | 82 ++++---
fs/proc/task_mmu.c | 2 +-
include/linux/pgtable.h | 51 +++-
mm/madvise.c | 8 +-
mm/memory.c | 8 +-
mm/mprotect.c | 2 +-
mm/mremap.c | 2 +-
mm/vmalloc.c | 6 +-
17 files changed, 781 insertions(+), 146 deletions(-)
create mode 100644 arch/s390/mm/ipte_batch.c
--
2.51.0
next reply other threads:[~2026-04-15 15:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 15:01 Alexander Gordeev [this message]
2026-04-15 15:01 ` [PATCH v2 1/6] mm: Make lazy MMU mode context-aware Alexander Gordeev
2026-04-15 15:01 ` [PATCH v2 2/6] mm/pgtable: Fix bogus comment to clear_not_present_full_ptes() Alexander Gordeev
2026-04-15 15:01 ` [PATCH v2 3/6] s390/mm: Complete ptep_get() conversion Alexander Gordeev
2026-04-15 15:01 ` [PATCH v2 4/6] s390/mm: Make PTC and UV call order consistent Alexander Gordeev
2026-04-15 15:01 ` [PATCH v2 5/6] s390/mm: Batch PTE updates in lazy MMU mode Alexander Gordeev
2026-04-15 15:01 ` [PATCH v2 6/6] s390/mm: Allow lazy MMU mode disabling Alexander Gordeev
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=cover.1776264097.git.agordeev@linux.ibm.com \
--to=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=david@redhat.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
/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