This commit adds refscale readers based on local_bh_disable() and
local_bh_enable() ("refscale.scale_type=bh"). On my x86 laptop, these
are about 4.9ns.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
kernel/rcu/refscale.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/refscale.c b/kernel/rcu/refscale.c
index 266a3fa94b54..1faed90231ab 100644
--- a/kernel/rcu/refscale.c
+++ b/kernel/rcu/refscale.c
@@ -636,6 +636,37 @@ static const struct ref_scale_ops jiffies_ops = {
.name = "jiffies"
};
+static void ref_bh_section(const int nloops)
+{
+ int i;
+
+ preempt_disable();
+ for (i = nloops; i >= 0; i--) {
+ local_bh_disable();
+ local_bh_enable();
+ }
+ preempt_enable();
+}
+
+static void ref_bh_delay_section(const int nloops, const int udl, const int ndl)
+{
+ int i;
+
+ preempt_disable();
+ for (i = nloops; i >= 0; i--) {
+ local_bh_disable();
+ un_delay(udl, ndl);
+ local_bh_enable();
+ }
+ preempt_enable();
+}
+
+static const struct ref_scale_ops bh_ops = {
+ .readsection = ref_bh_section,
+ .delaysection = ref_bh_delay_section,
+ .name = "bh"
+};
+
static void ref_irq_section(const int nloops)
{
int i;
@@ -1236,7 +1267,8 @@ ref_scale_init(void)
static const struct ref_scale_ops *scale_ops[] = {
&rcu_ops, &srcu_ops, &srcu_fast_ops, RCU_TRACE_OPS RCU_TASKS_OPS
&refcnt_ops, &rwlock_ops, &rwsem_ops, &lock_ops, &lock_irq_ops,
- &acqrel_ops, &sched_clock_ops, &clock_ops, &jiffies_ops, &irq_ops, &irqsave_ops,
+ &acqrel_ops, &sched_clock_ops, &clock_ops, &jiffies_ops,
+ &bh_ops, &irq_ops, &irqsave_ops,
&typesafe_ref_ops, &typesafe_lock_ops, &typesafe_seqlock_ops,
};
--
2.40.1On 2025-11-02 14:49:43 [-0800], Paul E. McKenney wrote:
> --- a/kernel/rcu/refscale.c
> +++ b/kernel/rcu/refscale.c
> @@ -636,6 +636,37 @@ static const struct ref_scale_ops jiffies_ops = {
> .name = "jiffies"
> };
>
> +static void ref_bh_section(const int nloops)
> +{
> + int i;
> +
> + preempt_disable();
> + for (i = nloops; i >= 0; i--) {
> + local_bh_disable();
This (preempt off followed by bh off) may cause warnings. That would be
bh is disabled on the CPU, it gets preempted by _this_ which disables
first preemption and then bh.
I hid the code under CONFIG_PREEMPT_RT_NEEDS_BH_LOCK so it shouldn't be
a problem in the long term I think. So just if you see a warning here
under RT you know why :)
> + local_bh_enable();
> + }
> + preempt_enable();
> +}
Sebastian
On Tue, Nov 11, 2025 at 04:38:03PM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-11-02 14:49:43 [-0800], Paul E. McKenney wrote:
> > --- a/kernel/rcu/refscale.c
> > +++ b/kernel/rcu/refscale.c
> > @@ -636,6 +636,37 @@ static const struct ref_scale_ops jiffies_ops = {
> > .name = "jiffies"
> > };
> >
> > +static void ref_bh_section(const int nloops)
> > +{
> > + int i;
> > +
> > + preempt_disable();
> > + for (i = nloops; i >= 0; i--) {
> > + local_bh_disable();
>
> This (preempt off followed by bh off) may cause warnings. That would be
> bh is disabled on the CPU, it gets preempted by _this_ which disables
> first preemption and then bh.
> I hid the code under CONFIG_PREEMPT_RT_NEEDS_BH_LOCK so it shouldn't be
> a problem in the long term I think. So just if you see a warning here
> under RT you know why :)
Huh. Would migrate_disable() be appropriate? Or I suppose I could just
let it migrate on RT. So how about the fix shown below?
Thanx, Paul
> > + local_bh_enable();
> > + }
> > + preempt_enable();
> > +}
>
> Sebastian
------------------------------------------------------------------------
diff --git a/kernel/rcu/refscale.c b/kernel/rcu/refscale.c
index 07a313782dfd..5a692a3b93fa 100644
--- a/kernel/rcu/refscale.c
+++ b/kernel/rcu/refscale.c
@@ -887,25 +887,29 @@ static void ref_bh_section(const int nloops)
{
int i;
- preempt_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_disable();
for (i = nloops; i >= 0; i--) {
local_bh_disable();
local_bh_enable();
}
- preempt_enable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_enable();
}
static void ref_bh_delay_section(const int nloops, const int udl, const int ndl)
{
int i;
- preempt_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_disable();
for (i = nloops; i >= 0; i--) {
local_bh_disable();
un_delay(udl, ndl);
local_bh_enable();
}
- preempt_enable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_enable();
}
static const struct ref_scale_ops bh_ops = {
On 2025-11-11 11:21:04 [-0800], Paul E. McKenney wrote:
> On Tue, Nov 11, 2025 at 04:38:03PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2025-11-02 14:49:43 [-0800], Paul E. McKenney wrote:
> > > --- a/kernel/rcu/refscale.c
> > > +++ b/kernel/rcu/refscale.c
> > > @@ -636,6 +636,37 @@ static const struct ref_scale_ops jiffies_ops = {
> > > .name = "jiffies"
> > > };
> > >
> > > +static void ref_bh_section(const int nloops)
> > > +{
> > > + int i;
> > > +
> > > + preempt_disable();
> > > + for (i = nloops; i >= 0; i--) {
> > > + local_bh_disable();
> >
> > This (preempt off followed by bh off) may cause warnings. That would be
> > bh is disabled on the CPU, it gets preempted by _this_ which disables
> > first preemption and then bh.
> > I hid the code under CONFIG_PREEMPT_RT_NEEDS_BH_LOCK so it shouldn't be
> > a problem in the long term I think. So just if you see a warning here
> > under RT you know why :)
>
> Huh. Would migrate_disable() be appropriate? Or I suppose I could just
> let it migrate on RT. So how about the fix shown below?
Depends on what you want to achieve. Even with that bh-disable you can
be preempted but you can't migrate to another CPU.
That preempt-disable() will keep the RCU read section open during
bh-disable/ enable but migrate_disable() won't. But this not something I
need to explain to you ;)
If that (to be within a RCU read section) is you intention you could
explicitly add a rcu_read_lock() there.
The change you suggested won't have the problem I mentioned.
> Thanx, Paul
Sebastian
On Wed, Nov 12, 2025 at 10:14:52AM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-11-11 11:21:04 [-0800], Paul E. McKenney wrote:
> > On Tue, Nov 11, 2025 at 04:38:03PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2025-11-02 14:49:43 [-0800], Paul E. McKenney wrote:
> > > > --- a/kernel/rcu/refscale.c
> > > > +++ b/kernel/rcu/refscale.c
> > > > @@ -636,6 +636,37 @@ static const struct ref_scale_ops jiffies_ops = {
> > > > .name = "jiffies"
> > > > };
> > > >
> > > > +static void ref_bh_section(const int nloops)
> > > > +{
> > > > + int i;
> > > > +
> > > > + preempt_disable();
> > > > + for (i = nloops; i >= 0; i--) {
> > > > + local_bh_disable();
> > >
> > > This (preempt off followed by bh off) may cause warnings. That would be
> > > bh is disabled on the CPU, it gets preempted by _this_ which disables
> > > first preemption and then bh.
> > > I hid the code under CONFIG_PREEMPT_RT_NEEDS_BH_LOCK so it shouldn't be
> > > a problem in the long term I think. So just if you see a warning here
> > > under RT you know why :)
> >
> > Huh. Would migrate_disable() be appropriate? Or I suppose I could just
> > let it migrate on RT. So how about the fix shown below?
>
> Depends on what you want to achieve. Even with that bh-disable you can
> be preempted but you can't migrate to another CPU.
Mostly just trying to measure the overhead of a local_bh_disable()
and local_bh_enable() pair. Yes, I understand that this is a bit
iffy these days, but it at least gets us some indication of problems
like this one:
https://lore.kernel.org/all/e7d539ed-ced0-4b96-8ecd-048a5b803b85@paulmck-laptop/
> That preempt-disable() will keep the RCU read section open during
> bh-disable/ enable but migrate_disable() won't. But this not something I
> need to explain to you ;)
Not necessary most of the time, anyway. ;-)
> If that (to be within a RCU read section) is you intention you could
> explicitly add a rcu_read_lock() there.
> The change you suggested won't have the problem I mentioned.
Very good, thank you! I am keeping it as an "EXP" (as in "experimental")
commit in my -rcu tree for the time being, given that it sounds like
you are looking to fix this within -rt.
Thanx, Paul
© 2016 - 2026 Red Hat, Inc.