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
