From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
Jirka Hladky <jhladky@redhat.com>,
paulmck@kernel.org
Cc: maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
mpe@ellerman.id.au, npiggin@gmail.com, bigeasy@linutronix.de,
will@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
Date: Tue, 28 Jul 2026 10:57:57 +0530 [thread overview]
Message-ID: <82752e9b-ed94-4253-ac5f-83cd3c91d569@linux.ibm.com> (raw)
In-Reply-To: <f81777c3-e341-4ec5-8d61-b333d7170b3f@kernel.org>
Hi Paul, Christophe,
On 7/27/26 11:59 PM, Christophe Leroy (CS GROUP) wrote:
> Hi Shrikanth,
>
>
> That's right with CONFIG_PREEMPT_DYNAMIC=y
>
> With CONFIG_PREEMT_DYNAMIC=n:
> - CONFIG_PREEMPT (full) implies CONFIG_PREEMPT_RCU
> - CONFIG_PREEMPT_LAZY (lazy) doesn't imply CONFIG_PREEMPT_RCU
>
> because of kernel/rcu/Kconfig,
>
> config PREEMPT_RCU
> bool
> default y if (PREEMPT || PREEMPT_RT || PREEMPT_DYNAMIC)
> select TREE_RCU
>
> Christophe
>
>
Right.
Looks like __rcu_read_unlock can set need_resched bit if it find irq were disabled
and rcu_read_unlock_special.s is set. I don't have much clue about it.
So, after seeing __rcu_read_unlock for PREEMPT_RCU I have these concerns now.
In current upstream, lazy is a preemption mode with preempt_enable being a preemptible point,
1. If PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n, then PREEMPT_RCU=n. That seems wrong. It is supposed to
do the preemption checks, since preempt_count is actual count with lazy preemption.
2. PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n and PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y are supposed
to be similar w.r.t to performance. Promise of PREEMPT_DYNAMIC was the ability to
switch at runtime based on the user workload and his/her preference.
But with PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y, there is additional cost due to PREEMPT_RCU.
lazy being the middle ground w.r.t for decent performance, either PREEMPT_RCU should either kick in
for both cases or bail out for both.
Before 7.0
3. the same concerns would be true to PREEMPT_VOLUNTARY and PREEMPT_NONE with PREEMPT_DYNAMIC=y.
Those model never wanted a preemption, but PREEMPT_RCU could have forced a need_resched to be
set. Which is also likely wrong. No?
next prev parent reply other threads:[~2026-07-28 5:28 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
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 [this message]
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=82752e9b-ed94-4253-ac5f-83cd3c91d569@linux.ibm.com \
--to=sshegde@linux.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=chleroy@kernel.org \
--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