On Wed, Oct 18, 2023 at 10:31:46AM -0400, Steven Rostedt wrote:
> On Wed, 18 Oct 2023 15:16:12 +0200
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
> > > 14. The kernel/trace/trace_osnoise.c file's run_osnoise() function
> > > might need to do something for non-preemptible RCU to make
> > > up for the lack of cond_resched() calls. Maybe just drop the
> > > "IS_ENABLED()" and execute the body of the current "if" statement
> > > unconditionally.
>
> Right.
>
> I'm guessing you are talking about this code:
>
> /*
> * In some cases, notably when running on a nohz_full CPU with
> * a stopped tick PREEMPT_RCU has no way to account for QSs.
> * This will eventually cause unwarranted noise as PREEMPT_RCU
> * will force preemption as the means of ending the current
> * grace period. We avoid this problem by calling
> * rcu_momentary_dyntick_idle(), which performs a zero duration
> * EQS allowing PREEMPT_RCU to end the current grace period.
> * This call shouldn't be wrapped inside an RCU critical
> * section.
> *
> * Note that in non PREEMPT_RCU kernels QSs are handled through
> * cond_resched()
> */
> if (IS_ENABLED(CONFIG_PREEMPT_RCU)) {
> if (!disable_irq)
> local_irq_disable();
>
> rcu_momentary_dyntick_idle();
>
> if (!disable_irq)
> local_irq_enable();
> }
That is indeed the place!
> /*
> * For the non-preemptive kernel config: let threads runs, if
> * they so wish, unless set not do to so.
> */
> if (!disable_irq && !disable_preemption)
> cond_resched();
>
>
>
> If everything becomes PREEMPT_RCU, then the above should be able to be
> turned into just:
>
> if (!disable_irq)
> local_irq_disable();
>
> rcu_momentary_dyntick_idle();
>
> if (!disable_irq)
> local_irq_enable();
>
> And no cond_resched() is needed.
Even given that CONFIG_PREEMPT_RCU=n still exists, the fact that
run_osnoise() is running in kthread context with preemption and everything
else enabled (am I right?), then the change you suggest should work fine.
> > Again. There is no non-preemtible RCU with this model, unless I'm
> > missing something important here.
>
> Daniel?
But very happy to defer to Daniel. ;-)
Thanx, Paul
