arch/s390/include/asm/entry-percpu.h | 71 ++---- arch/s390/include/asm/lowcore.h | 5 +- arch/s390/include/asm/percpu.h | 354 +++++++++++++++++---------- arch/s390/kernel/irq.c | 10 +- arch/s390/kernel/nmi.c | 4 +- arch/s390/kernel/traps.c | 4 +- 6 files changed, 248 insertions(+), 200 deletions(-)
v4: - With the change to la instead of agrk also the register pair cannot be mapped to gpr0/gpr1 anymore, since all three registers involved in pcpu operations are now used as base or index registers. If gpr0 is used as base or index register the corresponding instructions treat the content of that register as zero, instead of using its real content. Fix that by using the "a" instead if "d" constraint for register pairs. Also add another sanity check to cover this. [Sashiko] v3: - Add various sanity checks to enforce correct register usage [Mark Rutland] - Use %N instead of %M operand modifier to access odd register of a register pair in inline assemblies. Strictly speaking this is not correct, since %N is supposed to be used for DImode operands and %M for TImode operands. However both gcc and clang handle them identical, and there is an existing user of %N in the kernel since many years. Therefore use %N to get rid of the not yet released clang 24 dependency. [Christian Borntraeger] - Use la (load address) instruction with base and index register to generate a CPUs percpu variable address instead of agrk. la is available for all architecture levels. This removes the z196 dependency as minimum architecture level. [Christian Borntraeger] - Change coding style at some places, and fix various typos in commit messages and comments. - Fix compile error caused by missing semicolon. v2: - Yet another brown paper bug: Re-add CPU migration check to last patch. Unconditionally recalculating and updating the percpu variable address and percpu offset register can corrupt previous context register state in several cases (not only the single case reported by Sashiko). v1: Most of this is only about cleaning up the percpu code after preemptible this_cpu_*() operations have been implemented. The first ten patches are all more or less trivial cleanup patches trying to make the code shorter and more readable. The only non-trivial patch is the last one, which converts s390's this_cpu_*() operations to use a similar scheme like Mark Rutland provided it for arm64 [1]. This allows to simplify the irq entry and exit path, however at the cost of slightly worse code for this_cpu_*() operations. The simplified irq entry and exit code seems to be worth it. Usable performance numbers are not available yet, however I don't expect big difference to before. [1] https://lore.kernel.org/all/20260904161758.376504-1-mark.rutland@arm.com/ Thanks, Heiko Heiko Carstens (11): s390/percpu: Fix comment typo s390/percpu: Add sanity check to GEN_MVIY macro s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS s390/percpu: Let MVIY_PERCPU() calculate alternative displacement s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines s390/percpu: Rename inline assembly symbolic names s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies s390/percpu: Use percpu code section for this_cpu_cmpxchg128() s390/percpu: Use percpu code section for this_cpu_xchg() s390/percpu: Use percpu code section for this_cpu_cmpxchg() s390/percpu: Rework to simplify percpu_entry() and percpu_exit() arch/s390/include/asm/entry-percpu.h | 71 ++---- arch/s390/include/asm/lowcore.h | 5 +- arch/s390/include/asm/percpu.h | 354 +++++++++++++++++---------- arch/s390/kernel/irq.c | 10 +- arch/s390/kernel/nmi.c | 4 +- arch/s390/kernel/traps.c | 4 +- 6 files changed, 248 insertions(+), 200 deletions(-) -- 2.53.0
On 21/09/2026 17:57, Heiko Carstens wrote:
[..snip..]
> v1:
> Most of this is only about cleaning up the percpu code after preemptible
> this_cpu_*() operations have been implemented. The first ten patches are
> all more or less trivial cleanup patches trying to make the code shorter
> and more readable.
>
> The only non-trivial patch is the last one, which converts s390's
> this_cpu_*() operations to use a similar scheme like Mark Rutland
> provided it for arm64 [1]. This allows to simplify the irq entry and exit
> path, however at the cost of slightly worse code for this_cpu_*()
> operations.
>
> The simplified irq entry and exit code seems to be worth it. Usable
> performance numbers are not available yet, however I don't expect big
> difference to before.
>
> [1] https://lore.kernel.org/all/20260904161758.376504-1-mark.rutland@arm.com/
>
> Thanks,
> Heiko
>
> Heiko Carstens (11):
> s390/percpu: Fix comment typo
> s390/percpu: Add sanity check to GEN_MVIY macro
> s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS
> s390/percpu: Let MVIY_PERCPU() calculate alternative displacement
> s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines
> s390/percpu: Rename inline assembly symbolic names
> s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies
> s390/percpu: Use percpu code section for this_cpu_cmpxchg128()
> s390/percpu: Use percpu code section for this_cpu_xchg()
> s390/percpu: Use percpu code section for this_cpu_cmpxchg()
> s390/percpu: Rework to simplify percpu_entry() and percpu_exit()
>
> arch/s390/include/asm/entry-percpu.h | 71 ++----
> arch/s390/include/asm/lowcore.h | 5 +-
> arch/s390/include/asm/percpu.h | 354 +++++++++++++++++----------
> arch/s390/kernel/irq.c | 10 +-
> arch/s390/kernel/nmi.c | 4 +-
> arch/s390/kernel/traps.c | 4 +-
> 6 files changed, 248 insertions(+), 200 deletions(-)
>
Hi all,
I did some benchmarking for this patch series.
Used a shared LPAR with 24 CPUs (12 cores w SMT2).
Base commit: f0100363d8c3 ("Merge tag 'xfs-fixes-7.3-rc5' of
gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux")
Some of the benchmark runs show +-5% standard deviation which can
be attributed to s390 being a virtualized system. Each run has been
repeated five times to circumvent the effects of standard deviation.
(In the odd case where baseline has -5% and patched run has +5%
deviation, the comparison can show ~+10% improvements which is highly
misleading).
Overall, the benchmarks do not show any real difference between baseline
and patched kernels;
1-) Hackbench
========================================================================
Repeated hackbench runs with different group and fd count combinations;
[1, 2, 4, 8]
$ hackbench -T -p -l $loops -g $g -f $f
no real difference.
2-) Stress-ng
========================================================================
Repeated stress-ng runs with range of stressors: [6, $(nproc)]
# 3d matrix operations
$ stress-ng --matrix-3d $cpu --matrix-3d-method mult --timeout 10
# repeated mmap() and munmap() operations and also writing to the
# allocated memory.
$ stress-ng --vm $cpu --vm-bytes 128M --timeout 10
# starts workers that each fork off 32 child processes. Each child
# tries to allocate some memory. Child processes use madvise and memset
# to produce VM activity.
$ stress-ng --mmapfork $cpu --mmapfork-bytes 128M --timeout 10
no real difference.
3-) Openblas Benchmark
========================================================================
Repeated matrix operations with different size of 3d matrices.
$ make -j$(nproc) \
USE_OPENMP=1 \
NUM_THREADS=$(nproc)\
NOFORTRAN=1 > /dev/null 2>&1
$ make -C benchmark sgemm.goto \
USE_OPENMP=1 \
NUM_THREADS=$(nproc) \
NOFORTRAN=1 > /dev/null 2>&1
$ OPENBLAS_LOOPS=50 sgemm.goto
no real difference between runs.
4-) Compiling kernel
========================================================================
Linux kernel compilation
$ make clean
$ make mrproper
$ make defconfig
$ time make -j$(nproc)
no real difference between runs.
On Tue, Sep 22, 2026 at 05:37:14PM +0200, Mete Durlu wrote:
> On 21/09/2026 17:57, Heiko Carstens wrote:
> [..snip..]
> > The only non-trivial patch is the last one, which converts s390's
> > this_cpu_*() operations to use a similar scheme like Mark Rutland
> > provided it for arm64 [1]. This allows to simplify the irq entry and exit
> > path, however at the cost of slightly worse code for this_cpu_*()
> > operations.
...
> Hi all,
>
> I did some benchmarking for this patch series.
>
> Used a shared LPAR with 24 CPUs (12 cores w SMT2).
>
> Base commit: f0100363d8c3 ("Merge tag 'xfs-fixes-7.3-rc5' of
> gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux")
>
> Some of the benchmark runs show +-5% standard deviation which can
> be attributed to s390 being a virtualized system. Each run has been
> repeated five times to circumvent the effects of standard deviation.
> (In the odd case where baseline has -5% and patched run has +5%
> deviation, the comparison can show ~+10% improvements which is highly
> misleading).
>
> Overall, the benchmarks do not show any real difference between baseline
> and patched kernels;
Mete, thanks a lot for running the benchmarks!
This confirms that we can move forward including the last patch of this series.
On 22/09/2026 20:22, Heiko Carstens wrote:
> On Tue, Sep 22, 2026 at 05:37:14PM +0200, Mete Durlu wrote:
>> On 21/09/2026 17:57, Heiko Carstens wrote:
>> [..snip..]
>>> The only non-trivial patch is the last one, which converts s390's
>>> this_cpu_*() operations to use a similar scheme like Mark Rutland
>>> provided it for arm64 [1]. This allows to simplify the irq entry and exit
>>> path, however at the cost of slightly worse code for this_cpu_*()
>>> operations.
> ...
>> Hi all,
>>
>> I did some benchmarking for this patch series.
>>
>> Used a shared LPAR with 24 CPUs (12 cores w SMT2).
>>
>> Base commit: f0100363d8c3 ("Merge tag 'xfs-fixes-7.3-rc5' of
>> gitolite.kernel.org:/pub/scm/fs/xfs/xfs-linux")
>>
>> Some of the benchmark runs show +-5% standard deviation which can
>> be attributed to s390 being a virtualized system. Each run has been
>> repeated five times to circumvent the effects of standard deviation.
>> (In the odd case where baseline has -5% and patched run has +5%
>> deviation, the comparison can show ~+10% improvements which is highly
>> misleading).
>>
>> Overall, the benchmarks do not show any real difference between baseline
>> and patched kernels;
>
> Mete, thanks a lot for running the benchmarks!
>
> This confirms that we can move forward including the last patch of this series.
I also gave it a spin on a zVM instance. Results are quite similar.
FWIW, here is my tested by;
Tested-by: Mete Durlu <meted@linux.ibm.com>
© 2016 - 2026 Red Hat, Inc.