Re: [PATCH 2/2] rcutorture: Nudge ksoftirqd priority for RCU boost testing

[Valentin Schneider <valentin.schneider@arm.com>]

On 04/08/21 15:53, Paul E. McKenney wrote:
> On Wed, Aug 04, 2021 at 11:18:11AM +0100, Valentin Schneider wrote:
>>
>> Hm so v5.13-rt1 has this commit:
>>
>>   5e59fba573e6 ("rcutorture: Fix testing of RCU priority boosting")
>>
>> which gates RCU boost torture testing under CONFIG_PREEMPT_RT. Now, AFAICT
>> the TIMER_SOFTIRQ priority problem is there regardless of
>> CONFIG_PREEMPT_RT, so this patch would (should?) make sense even on
>> !CONFIG_PREEMPT_RT.
>
> What rcutorture scenario TREE03 does is to boot with tree.use_softirq=0
> and threadirqs.  I see your point about timers and softirq, but this
> does run reliably for me.
>
> Ah, I see why.  Commit ea6d962e80b6 ("rcutorture: Judge RCU priority
> boosting on grace periods, not callbacks") includes boosting the priority
> of the ksoftirqd kthreads.  But only when running rcutorture builtin,
> not as a module.  Here is the code in rcu_torture_init():
>
>               // Testing RCU priority boosting requires rcutorture do
>               // some serious abuse.  Counter this by running ksoftirqd
>               // at higher priority.
>               if (IS_BUILTIN(CONFIG_RCU_TORTURE_TEST)) {
>                       for_each_online_cpu(cpu) {
>                               struct sched_param sp;
>                               struct task_struct *t;
>
>                               t = per_cpu(ksoftirqd, cpu);
>                               WARN_ON_ONCE(!t);
>                               sp.sched_priority = 2;
>                               sched_setscheduler_nocheck(t, SCHED_FIFO, &sp);
>                       }
>               }
>
> I take it that you were running rcutorture as a module?
>
> This describes how to run it built-in, if that works for you:
>
> https://paulmck.livejournal.com/61432.html
>
> More specifically: https://paulmck.livejournal.com/57769.html
>
> Alternatively, the "IS_BUILTIN(CONFIG_RCU_TORTURE_TEST)" check could be
> removed in the above code, and the ksoftirqd kthreads could have their
> original priority restored in rcu_torture_cleanup().
>
> Thoughts?
>

I actually run rcutorture as a builtin, but from what I can tell the above
patch came in v5.14-rc1, and ofc I'm running my tests on v5.13-rt1... I
should have paid closer attention to what was in the latest mainline,
apologies for the noise. 

FWIW tweaking ksoftirqd priority only when the torture module is builtin
makes sense to me.