linux-kernel - Re: [PATCH v2 04/12] rcutorture: Make torture.sh --do-rt use CONFIG_PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52b014c0-8f3e-401a-9598-99a6a264601c@paulmck-laptop>
Date: Wed, 2 Apr 2025 11:51:41 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: rcu@...r.kernel.org, Joel Fernandes <joelagnelf@...dia.com>,
	linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org
Subject: Re: [PATCH v2 04/12] rcutorture: Make torture.sh --do-rt use
 CONFIG_PREEMPT_RT

On Wed, Apr 02, 2025 at 09:42:11AM +0200, Sebastian Andrzej Siewior wrote:
> On 2025-03-31 14:03:06 [-0700], Paul E. McKenney wrote:
> > The torture.sh --do-rt command-line parameter is intended to mimic -rt
> > kernels.  Now that CONFIG_PREEMPT_RT is upstream, this commit makes this
> > mimicking more precise.
> > 
> > Note that testing of RCU priority boosting is disabled in favor
> > of forward-progress testing of RCU callbacks.  If it turns out to be
> > possible to make kernels built with CONFIG_PREEMPT_RT=y to tolerate
> > testing of both, both will be enabled.
> 
> Not sure what you point at here: You can build a PREEMPT_RT kernel and
> RCU boosting is enabled by default. You could disable it if needed.

The issue is not the enabling of RCU priority boosting itself, but
instead the rcutorture testing of it.  And if it makes you feel better,
this problem is now sometimes affecting mainline testing.  So maybe
rcutorture will need to do only one form of overload testing at a time,
maybe using a mutex or some such.

> Config wise you set CONFIG_PREEMPT_LAZY=n but in general
> CONFIG_PREEMPT_LAZY=y should be used if possible. The preemption while
> holding a sleeping spinlock is somehow bad for performance if a lot of
> threads ask for it. But then it probably doesn't matter for testing.

For general use, agreed.  But in this case, I want CONFIG_PREEMPT_RT=y,
so I must also end up with CONFIG_PREEMPT_LAZY=n, right?  Though to your
point, that happens by default, so I don't need to explicitly specify it.

Or if the concern is general rcutorture testing of CONFIG_PREEMPT_LAZY=y,
that is done by the TREE07 and TREE10 rcutorture scenarios, both of
which I run regularly.

> You do set rcupdate.rcu_normal and rcupdate.rcu_expedited but RT has
> rcu_normal_after_boot set by default. Not sure if this makes any
> difference but I *think* that normal wins here.

I should definitely align with -rt common practice regardless.  Plus
rcupdate.rcu_normal_after_boot is set by default by PREEMPT_RT, so
there is no need to separately specify it.

On the other hand, the variant that does use expedited grace periods
needs to explicitly disable rcu_normal_after_boot.

Do real-time kernels normally enable NO_HZ_FULL?  Or do event-driven
real-time workloads prefer NO_HZ_IDLE?  I am currently guessing
NO_HZ_IDLE.  (I test NO_HZ_FULL in conjunction with expedited grace
periods in the second run.)

Please see incremental patch below, which I am testing.

						Thanx, Paul

> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>

------------------------------------------------------------------------

diff --git a/tools/testing/selftests/rcutorture/bin/torture.sh b/tools/testing/selftests/rcutorture/bin/torture.sh
index ed43aea91c7d9..6d1a84f3f6315 100755
--- a/tools/testing/selftests/rcutorture/bin/torture.sh
+++ b/tools/testing/selftests/rcutorture/bin/torture.sh
@@ -481,13 +481,13 @@ then
 	# -rt doesn't like its interaction with testing of callback
 	# flooding.
 
-	# With all post-boot grace periods forced to normal.
-	torture_bootargs="rcupdate.rcu_cpu_stall_suppress_at_boot=1 torture.disable_onoff_at_boot rcupdate.rcu_task_stall_timeout=30000 rcutorture.test_boost=0 rcupdate.rcu_normal=1"
-	torture_set "rcurttorture" tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration "$duration_rcutorture" --configs "TREE03" --kconfig "CONFIG_PREEMPT_LAZY=n CONFIG_PREEMPT_RT=y CONFIG_EXPERT=y" --trust-make
+	# With all post-boot grace periods forced to normal (default for PREEMPT_RT).
+	torture_bootargs="rcupdate.rcu_cpu_stall_suppress_at_boot=1 torture.disable_onoff_at_boot rcupdate.rcu_task_stall_timeout=30000 rcutorture.test_boost=0 rcutorture.preempt_duration=0"
+	torture_set "rcurttorture" tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration "$duration_rcutorture" --configs "TREE03" --kconfig "CONFIG_PREEMPT_RT=y CONFIG_EXPERT=y CONFIG_HZ_PERIODIC=n CONFIG_NO_HZ_IDLE=y" --trust-make
 
 	# With all post-boot grace periods forced to expedited.
-	torture_bootargs="rcupdate.rcu_cpu_stall_suppress_at_boot=1 torture.disable_onoff_at_boot rcupdate.rcu_task_stall_timeout=30000 rcutorture.test_boost=0 rcupdate.rcu_expedited=1"
-	torture_set "rcurttorture-exp" tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration "$duration_rcutorture" --configs "TREE03" --kconfig "CONFIG_PREEMPT_LAZY=n CONFIG_PREEMPT_RT=y CONFIG_EXPERT=y" --trust-make
+	torture_bootargs="rcupdate.rcu_cpu_stall_suppress_at_boot=1 torture.disable_onoff_at_boot rcupdate.rcu_task_stall_timeout=30000 rcutorture.test_boost=0 rcupdate.rcu_normal_after_boot=0 rcupdate.rcu_expedited=1 rcutorture.preempt_duration=0"
+	torture_set "rcurttorture-exp" tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration "$duration_rcutorture" --configs "TREE03" --kconfig "CONFIG_PREEMPT_RT=y CONFIG_EXPERT=y CONFIG_HZ_PERIODIC=n CONFIG_NO_HZ_FULL=y" --trust-make
 fi
 
 if test "$do_rcu_rust" = "yes"