From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Jirka Hladky <jhladky@redhat.com>
Cc: maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
christophe.leroy@csgroup.eu, mpe@ellerman.id.au,
npiggin@gmail.com, bigeasy@linutronix.de, will@kernel.org,
linux-kernel@vger.kernel.org,
"Paul E . McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
Date: Mon, 27 Jul 2026 18:04:50 +0530 [thread overview]
Message-ID: <e74ac6d4-6ea5-4600-9e01-2ab215235ffa@linux.ibm.com> (raw)
In-Reply-To: <CAE4VaGB-W9i0nNzH=VN9GJr6Dy9R46NtMC3V3ELUxdDhypj8bw@mail.gmail.com>
On 7/27/26 3:43 PM, Jirka Hladky wrote:
> Hi Shrikanth,
>
[...]
>
> The real question is: why does enabling PREEMPT_RCU cost ~33% on
> ppc64le but only ~3% on x86_64? The answer is that x86_64's TSO
> memory model makes the barriers in __rcu_read_lock/__rcu_read_unlock
> essentially free, while ppc64le's weak ordering requires explicit
> lwsync/isync instructions, which are expensive when called thousands
> of times per second in the SELinux AVC hot path.
>
Ensure when comparing the preemption modes are same or not.
x86 has dynamic preemption since long time. It might be possible in your
testing when you compared for x86, preemption modes were same, whereas in
case of powerpc you are comparing between voluntary vs lazy.
If it is voluntary vs lazy, this would simplify where to concentrate.
(You can easily do this with CONFIG_PREEMPT_DYNAMIC=n on a kernel before 7.0)
next prev parent reply other threads:[~2026-07-27 12:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-10 18:43 [PATCH v4 0/1] powerpc: Enable dynamic preemption Shrikanth Hegde
2025-02-10 18:43 ` [PATCH v4 1/1] powerpc: enable " Shrikanth Hegde
2026-07-26 18:33 ` Jirka Hladky
2026-07-27 4:18 ` Shrikanth Hegde
2026-07-27 10:13 ` Jirka Hladky
2026-07-27 10:28 ` Shrikanth Hegde
2026-07-27 10:35 ` Christophe Leroy (CS GROUP)
2026-07-27 16:12 ` Paul E. McKenney
2026-07-27 10:59 ` Jirka Hladky
2026-07-27 11:03 ` Shrikanth Hegde
2026-07-27 12:34 ` Shrikanth Hegde [this message]
2026-07-27 16:07 ` Paul E. McKenney
2026-07-27 16:50 ` Jirka Hladky
2026-07-27 17:10 ` Shrikanth Hegde
2026-07-27 18:29 ` Christophe Leroy (CS GROUP)
2026-07-28 5:27 ` Shrikanth Hegde
2026-07-28 0:26 ` Jirka Hladky
2026-07-28 5:11 ` Shrikanth Hegde
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=e74ac6d4-6ea5-4600-9e01-2ab215235ffa@linux.ibm.com \
--to=sshegde@linux.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=christophe.leroy@csgroup.eu \
--cc=jhladky@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=will@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