From: Heiko Carstens <hca@linux.ibm.com>
To: Alexander Gordeev <agordeev@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Juergen Christ <jchrist@linux.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: [PATCH v2 0/9] s390: Improve this_cpu operations
Date: Thu, 19 Mar 2026 13:04:54 +0100 [thread overview]
Message-ID: <20260319120503.4046659-1-hca@linux.ibm.com> (raw)
v2:
- Add proper PERCPU_PTR cast to most patches to avoid tons of sparse
warnings
- Add missing __packed attribute to insn structure [Sashiko [2]]
- Fix inverted if condition [Sashiko [2]]
- Add missing user_mode() check [Sashiko [2]]
- Move percpu_entry() call in front of irqentry_enter() call in all
entry paths to avoid that potential this_cpu() operations overwrite
the not-yet saved percpu code section indicator [Sashiko [2]]
[2] https://sashiko.dev/#/patchset/20260317195436.2276810-1-hca%40linux.ibm.com
v1:
This is a follow-up to Peter Zijlstra's in-kernel rseq RFC [1].
With the intended removal of PREEMPT_NONE this_cpu operations based on
atomic instructions, guarded with preempt_disable()/preempt_enable() pairs,
become more expensive: the preempt_disable() / preempt_enable() pairs are
not optimized away anymore during compile time.
In particular the conditional call to preempt_schedule_notrace() after
preempt_enable() adds additional code and register pressure.
To avoid this Peter suggested an in-kernel rseq approach. While this would
certainly work, this series tries to come up with a solution which uses
less instructions and doesn't require to repeat instruction sequences.
The idea is that this_cpu operations based on atomic instructions are
guarded with mvyi instructions:
- The first mvyi instruction writes the register number, which contains
the percpu address variable to lowcore. This also indicates that a
percpu code section is executed.
- The first instruction following the mvyi instruction must be the ag
instruction which adds the percpu offset to the percpu address register.
- Afterwards the atomic percpu operation follows.
- Then a second mvyi instruction writes a zero to lowcore, which indicates
the end of the percpu code section.
- In case of an interrupt/exception/nmi the register number which was
written to lowcore is copied to the exception frame (pt_regs), and a zero
is written to lowcore.
- On return to the previous context it is checked if a percpu code section
was executed (saved register number not zero), and if the process was
migrated to a different cpu. If the percpu offset was already added to
the percpu address register (instruction address does _not_ point to the
ag instruction) the content of the percpu address register is adjusted so
it points to percpu variable of the new cpu.
All of this seems to work, but of course it could still be broken since I
missed some detail.
In total this series results in a kernel text size reduction of ~106kb. The
number of preempt_schedule_notrace() call sites is reduced from 7089 to
1577.
Note: this comes without any huge performance analysis, however all
microbenchmarks confirmed that the new code is at least as fast as the
old code, like expected.
[1] 20260223163843.GR1282955@noisy.programming.kicks-ass.net
Heiko Carstens (9):
s390/percpu: Provide arch_raw_cpu_ptr()
s390/alternatives: Add new ALT_TYPE_PERCPU type
s390/percpu: Infrastructure for more efficient this_cpu operations
s390/percpu: Use new percpu code section for arch_this_cpu_add()
s390/percpu: Use new percpu code section for arch_this_cpu_add_return()
s390/percpu: Use new percpu code section for arch_this_cpu_[and|or]()
s390/percpu: Provide arch_this_cpu_read() implementation
s390/percpu: Provide arch_this_cpu_write() implementation
s390/percpu: Remove one and two byte this_cpu operation implementation
arch/s390/boot/alternative.c | 7 +
arch/s390/include/asm/alternative.h | 5 +
arch/s390/include/asm/entry-percpu.h | 57 ++++++
arch/s390/include/asm/lowcore.h | 3 +-
arch/s390/include/asm/percpu.h | 259 ++++++++++++++++++++++-----
arch/s390/include/asm/ptrace.h | 2 +
arch/s390/kernel/alternative.c | 25 ++-
arch/s390/kernel/irq.c | 17 +-
arch/s390/kernel/nmi.c | 3 +
arch/s390/kernel/traps.c | 3 +
10 files changed, 330 insertions(+), 51 deletions(-)
create mode 100644 arch/s390/include/asm/entry-percpu.h
--
2.51.0
next reply other threads:[~2026-03-19 12:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 12:04 Heiko Carstens [this message]
2026-03-19 12:04 ` [PATCH v2 1/9] s390/percpu: Provide arch_raw_cpu_ptr() Heiko Carstens
2026-03-19 12:04 ` [PATCH v2 2/9] s390/alternatives: Add new ALT_TYPE_PERCPU type Heiko Carstens
2026-03-19 12:04 ` [PATCH v2 3/9] s390/percpu: Infrastructure for more efficient this_cpu operations Heiko Carstens
2026-03-19 12:04 ` [PATCH v2 4/9] s390/percpu: Use new percpu code section for arch_this_cpu_add() Heiko Carstens
2026-03-19 12:04 ` [PATCH v2 5/9] s390/percpu: Use new percpu code section for arch_this_cpu_add_return() Heiko Carstens
2026-03-19 12:05 ` [PATCH v2 6/9] s390/percpu: Use new percpu code section for arch_this_cpu_[and|or]() Heiko Carstens
2026-03-19 12:05 ` [PATCH v2 7/9] s390/percpu: Provide arch_this_cpu_read() implementation Heiko Carstens
2026-03-19 12:05 ` [PATCH v2 8/9] s390/percpu: Provide arch_this_cpu_write() implementation Heiko Carstens
2026-03-19 12:05 ` [PATCH v2 9/9] s390/percpu: Remove one and two byte this_cpu operation implementation Heiko Carstens
2026-03-19 13:56 ` [PATCH v2 0/9] s390: Improve this_cpu operations Peter Zijlstra
2026-03-20 11:39 ` Heiko Carstens
2026-03-20 11:44 ` Peter Zijlstra
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=20260319120503.4046659-1-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=jchrist@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=svens@linux.ibm.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