Re: [PATCH RFC 1/7] rcutorture: Rewrite RCU priority-boost test around a CPU-hungry reader

[Joel Fernandes <joelagnelf@nvidia.com>]

On 11/13/2026 10:53 AM, Sebastian Andrzej Siewior wrote:
> On 2026-11-11 16:38:19 [-0500], Joel Fernandes wrote:
>> The old boost test relies on RT throttling being disabled and on grace
>> periods taking too long, which is fragile.  Instead, each interval one
>> CPU runs a normal-priority reader that spins inside an RCU read-side
>> critical section until it has consumed test_boost_reader_ms of CPU time
>> (measured via sum_exec_runtime, so time spent preempted does not count),
>> while a SCHED_FIFO hog on the same CPU tries to starve it.  With RT
>> throttling enabled, an unboosted reader gets only about 5% of the CPU,
>> far less than it needs within test_boost_duration.  If the reader
>> finishes, boosting worked, otherwise it failed.
> 
> What I see from tracing is:
> 
> | rcu_torture_boo-2066    [001] d..2.   237.448002: sched_switch: prev_comm=rcu_torture_boo prev_pid=2066 prev_prio=120 prev_state=R+ ==> next_comm=rcu_torture_boo next_pid=93 next_prio=98
> 
> preempted as SCHED_OTHER
> 
> |          rcub/0-16      [003] d..3.   237.460085: sched_pi_setprio: comm=rcu_torture_boo pid=2066 oldprio=120 newprio=97
> 
> boosted shortly after
> 
> | rcu_torture_boo-93      [001] d..2.   237.460108: sched_switch: prev_comm=rcu_torture_boo prev_pid=93 prev_prio=98 prev_state=R+ ==> next_comm=rcu_torture_boo next_pid=2066 next_prio=97
> | rcu_torture_boo-2066    [001] d.h1.   237.463994: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=3908069 [ns]
> | rcu_torture_boo-2066    [001] d.h1.   237.467985: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=3991212 [ns]
> | rcu_torture_boo-2066    [001] d.h1.   237.471995: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=4009726 [ns]
> 
> back on CPU and not pushed away.
> |  rcu_torture_boo-2066    [001] dN.2.   238.397969: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=5311 [ns]
> |  rcu_torture_boo-2066    [001] d..2.   238.397975: sched_switch: prev_comm=rcu_torture_boo prev_pid=2066 prev_prio=97 prev_state=R+ ==> next_comm=kworker/1:3 next_pid=1386 next_prio=120
> |     kworker/1:1H-745     [001] d..2.   238.398067: sched_switch: prev_comm=kworker/1:1H prev_pid=745 prev_prio=100 prev_state=I ==> next_comm=rcu_torture_boo next_pid=2066 next_prio=97
> |  rcu_torture_boo-2066    [001] d.s3.   238.398122: sched_waking: comm=kworker/1:3 pid=1386 prio=120 target_cpu=001
> |  rcu_torture_boo-2066    [001] d.s4.   238.398124: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=63431 [ns]
> |  rcu_torture_boo-2066    [001] dNs4.   238.398128: sched_wakeup: comm=kworker/1:3 pid=1386 prio=120 target_cpu=001
> |  rcu_torture_boo-2066    [001] d..2.   238.398130: sched_switch: prev_comm=rcu_torture_boo prev_pid=2066 prev_prio=97 prev_state=R+ ==> next_comm=kworker/1:3 next_pid=1386 next_prio=120
> |      kworker/1:3-1386    [001] d..2.   238.398137: sched_switch: prev_comm=kworker/1:3 prev_pid=1386 prev_prio=120 prev_state=I ==> next_comm=rcu_torture_boo next_pid=2066 next_prio=97
> |  rcu_torture_boo-2066    [001] d.h1.   238.399986: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=1851337 [ns]
> |  rcu_torture_boo-2066    [001] d.h1.   238.400081: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=94860 [ns]
> 
> The fair_server preempts now and then.
> |  rcu_torture_boo-2066    [001] d.h1.   239.455988: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=4002590 [ns]
> |  rcu_torture_boo-2066    [001] d..3.   239.455999: sched_waking: comm=rcu_preempt pid=15 prio=97 target_cpu=000
> |  rcu_torture_boo-2066    [001] d..3.   239.456012: sched_waking: comm=rcu_exp_gp_kthr pid=18 prio=120 target_cpu=002
> |  rcu_torture_boo-2066    [001] d..3.   239.456023: sched_pi_setprio: comm=rcu_torture_boo pid=2066 oldprio=97 newprio=120
> |  rcu_torture_boo-2066    [001] d..3.   239.456024: sched_stat_runtime: comm=rcu_torture_boo pid=2066 runtime=35773 [ns]
> |  rcu_torture_boo-2066    [001] d..2.   239.456032: sched_switch: prev_comm=rcu_torture_boo prev_pid=2066 prev_prio=120 prev_state=R+ ==> next_comm=rcu_torture_boo next_pid=93 next_prio=98
> 
> Leaving the RCU section and getting de-boosted.
> 
> This looks good.
> 

Thank you for testing! I went through your other suggestions and they mostly
look good to me, so I will revise the series and post a v2.

> …
> 
>> Success testing: with the series applied and no other changes, run
>> TREE01 TREE02 TREE03 TREE08 TREE09 BUSTED-BOOST for 10 minutes each.
>> Every scenario ended "SUCCESS" with rtbf (boost failures) of 0 in 59 to
>> 83 boost intervals.  (BUSTED-BOOST can no longer fail by construction
>> because CONFIG_RCU_BOOST is now enabled automatically for preemptible
>> RCU.)
> 
> I didn't run the individual tests but checked in my rcu-tree setup that
> boosting works as it should and that it complains once it does not. And
> the throttling of the RT tasks has no visible impact.
Excellent, thanks!

Joel Fernandes