From: Yang Shi <yang@os.amperecomputing.com>
To: "Christoph Lameter (Ampere)" <cl@gentwo.org>,
Heiko Carstens <hca@linux.ibm.com>
Cc: David Laight <david.laight.linux@gmail.com>,
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>,
Peter Zijlstra <peterz@infradead.org>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v3 0/9] s390: Improve this_cpu operations
Date: Wed, 27 May 2026 13:38:06 -0700 [thread overview]
Message-ID: <d362d0cc-cdfc-4916-b779-fba62b3fb38c@os.amperecomputing.com> (raw)
In-Reply-To: <f417b97c-e321-6fe7-3a7b-a3a71b16f27b@gentwo.org>
On 5/27/26 12:09 PM, Christoph Lameter (Ampere) wrote:
> On Fri, 22 May 2026, Heiko Carstens wrote:
>
>> Also with the current proposal I only did some quick micro benchmarks,
>> which resulted in 0-1% improvement, which is in the expected range.
>>
>> It is amazing to see the performance improvements you see on arm64, however
>> I believe that is mainly because of the large amount of code which is
>> generated by the arm64 implementations of the preempt primitives
>> __preempt_count_add() and __preempt_count_dec_and_test().
> The code is generated if you have no arch specific per cpu mechanism and
> preemption must be supported. We have now the situation that we cannot
> switch off preemption support anymore.
>
> It seem that S390 has this mechanism in a small way and therefore can
> avoid the preempt enable/disable.
>
> It is not the quantity of code here. The preempt enable/disable can only
> be avoided if there is a single instruction doing the per cpu operation. A
> single instruction cannot be interupted and therefore is preemption safe.
>
>
>> That's a big difference to s390: for both primitives the result is a single
>> instruction.
> Ok then you can already use single instructions like x86 and will not have
> preempt enable/disable overhead.
I don't think S390 can do it in one single instruction. IIUC, Heiko
means preempt_enable/disable is a single instruction on s390, but it is
RMW on ARM64 (3 instructions for each).
Thanks,
Yang
>
> I am not sure what David Laight's code is supposed to do. Seems weird to
> me.
>
next prev parent reply other threads:[~2026-05-27 20:38 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 9:22 Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 1/9] s390/alternatives: Add new ALT_TYPE_PERCPU type Heiko Carstens
2026-05-20 12:43 ` David Laight
2026-05-20 13:50 ` Heiko Carstens
2026-05-20 14:16 ` Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 2/9] s390/percpu: Infrastructure for more efficient this_cpu operations Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 3/9] s390/percpu: Add missing do { } while (0) constructs Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 4/9] s390/percpu: Use new percpu code section for arch_this_cpu_add() Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 5/9] s390/percpu: Use new percpu code section for arch_this_cpu_add_return() Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 6/9] s390/percpu: Use new percpu code section for arch_this_cpu_[and|or]() Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 7/9] s390/percpu: Provide arch_this_cpu_read() implementation Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 8/9] s390/percpu: Provide arch_this_cpu_write() implementation Heiko Carstens
2026-05-20 9:22 ` [PATCH v3 9/9] s390/percpu: Remove one and two byte this_cpu operation implementation Heiko Carstens
2026-05-20 18:42 ` [PATCH v3 0/9] s390: Improve this_cpu operations Yang Shi
2026-05-20 22:34 ` David Laight
2026-05-21 0:23 ` Yang Shi
2026-05-21 10:17 ` David Laight
2026-05-21 16:57 ` Yang Shi
2026-05-21 17:55 ` David Laight
2026-05-21 20:46 ` Yang Shi
2026-05-21 22:13 ` David Laight
2026-05-21 23:41 ` Yang Shi
2026-05-21 10:23 ` David Laight
2026-05-21 17:48 ` Yang Shi
2026-05-21 10:37 ` Heiko Carstens
2026-05-21 17:47 ` Yang Shi
2026-05-22 9:18 ` Heiko Carstens
2026-05-27 19:09 ` Christoph Lameter (Ampere)
2026-05-27 20:38 ` Yang Shi [this message]
2026-05-28 8:36 ` David Laight
2026-05-27 23:44 ` Yang Shi
2026-05-28 9:03 ` David Laight
2026-05-28 19:19 ` Yang Shi
2026-05-28 20:34 ` David Laight
2026-05-28 14:14 ` Heiko Carstens
2026-05-28 17:14 ` David Laight
2026-05-28 18:39 ` Yang Shi
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=d362d0cc-cdfc-4916-b779-fba62b3fb38c@os.amperecomputing.com \
--to=yang@os.amperecomputing.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=cl@gentwo.org \
--cc=david.laight.linux@gmail.com \
--cc=gor@linux.ibm.com \
--cc=hca@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=sshegde@linux.ibm.com \
--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
all inboxes | Powered by JetHome®