All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Mete Durlu <meted@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Juergen Christ <jchrist@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v4 00/11] s390: More this_cpu_*() changes
Date: Tue, 22 Sep 2026 20:22:55 +0200	[thread overview]
Message-ID: <20260922182255.26236Cc2-hca@linux.ibm.com> (raw)
In-Reply-To: <dc01ef2f-3ed9-4b25-ae5f-1bd317df27cb@linux.ibm.com>

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.

  reply	other threads:[~2026-09-22 18:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 15:57 [PATCH v4 00/11] s390: More this_cpu_*() changes Heiko Carstens
2026-09-21 15:57 ` [PATCH v4 01/11] s390/percpu: Fix comment typo Heiko Carstens
2026-09-21 16:00   ` sashiko-bot
2026-09-21 15:57 ` [PATCH v4 02/11] s390/percpu: Add sanity check to GEN_MVIY macro Heiko Carstens
2026-09-21 16:03   ` sashiko-bot
2026-09-21 15:57 ` [PATCH v4 03/11] s390/lowcore: Remove _AC() from LOWCORE_ALT_ADDRESS Heiko Carstens
2026-09-21 16:07   ` sashiko-bot
2026-09-21 15:57 ` [PATCH v4 04/11] s390/percpu: Let MVIY_PERCPU() calculate alternative displacement Heiko Carstens
2026-09-21 16:15   ` sashiko-bot
2026-09-21 15:57 ` [PATCH v4 05/11] s390/percpu/lowcore: Add and use LC_PERCPU lowcore offset defines Heiko Carstens
2026-09-21 16:18   ` sashiko-bot
2026-09-21 15:58 ` [PATCH v4 06/11] s390/percpu: Rename inline assembly symbolic names Heiko Carstens
2026-09-21 16:19   ` sashiko-bot
2026-09-21 15:58 ` [PATCH v4 07/11] s390/percpu: Use __PCPU_BEGIN() and __PCPU_END() for inline assemblies Heiko Carstens
2026-09-21 16:23   ` sashiko-bot
2026-09-21 15:58 ` [PATCH v4 08/11] s390/percpu: Use percpu code section for this_cpu_cmpxchg128() Heiko Carstens
2026-09-21 16:29   ` sashiko-bot
2026-09-21 15:58 ` [PATCH v4 09/11] s390/percpu: Use percpu code section for this_cpu_xchg() Heiko Carstens
2026-09-21 16:34   ` sashiko-bot
2026-09-21 15:58 ` [PATCH v4 10/11] s390/percpu: Use percpu code section for this_cpu_cmpxchg() Heiko Carstens
2026-09-21 16:42   ` sashiko-bot
2026-09-21 15:58 ` [PATCH v4 11/11] s390/percpu: Rework to simplify percpu_entry() and percpu_exit() Heiko Carstens
2026-09-21 16:48   ` sashiko-bot
2026-09-22 15:37 ` [PATCH v4 00/11] s390: More this_cpu_*() changes Mete Durlu
2026-09-22 18:22   ` Heiko Carstens [this message]
2026-09-23  6:02     ` Mete Durlu
2026-09-26  6:53 ` 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=20260922182255.26236Cc2-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=iii@linux.ibm.com \
    --cc=jchrist@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=meted@linux.ibm.com \
    --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 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.