On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney wrote:
> > --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > @@ -39,9 +39,22 @@ mkdir $T
> >
> > cat > $T/init << '__EOF___'
> > #!/bin/sh
> > +# Run in userspace a few milliseconds every second. This helps to
> > +# exercise the NO_HZ_FULL portions of RCU.
> > while :
> > do
> > - sleep 1000000
> > + q=
> > + for i in \
> > + a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a \
> > + a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a \
> > + a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a \
> > + a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a \
> > + a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a \
> > + a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
>
> Ow. If there's no better way to do this, please do at least comment how many 'a's
> this is. (And why 186, exactly?)
Yeah, that is admittedly a bit strange. The reason for 186 occurrences of
"a" to one-time calibration, measuring a few millisecond's worth of delay.
> Please also consider calibrating the delay loop as you do in the C code.
Good point. And a quick web search finds me "date '+%s%N'", which gives
me nanoseconds since the epoch. I probably don't want to do a 2038 to
myself (after all, I might still be alive then), so I should probably try
to make something work with "date '+%N'". Or use something like this:
$ date '+%4N'; date '+%4N';date '+%4N'; date '+%4N'
6660
6685
6697
6710
Ah, but that means I need to add the "date" command to my initrd, doesn't
it? And calculation requires either bash or the "test" command. And it
would be quite good to restrict this to what can be done with Bourne shell
built-in commands, since a big point of this is to maintain a small-sized
initrd. :-/
So how about the following patch, which attempts to explain the situation?
Thanx, Paul
------------------------------------------------------------------------
commit 23c304cbeda435acd4096ab3213502d6ae9720f3
Author: Paul E. McKenney <paulmck@xxxxxxxxxxxxx>
Date: Tue Dec 4 14:59:12 2018 -0800
torture: Explain odd "for" loop in mkinitrd.sh
Why a Bourne-shell "for" loop? And why 186 instances of "a"? This commit
adds a shell comment to present the answer to these mysteries.
Reported-by: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxx>
diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
index da298394daa2..1df0bbbfde7c 100755
--- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
+++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
@@ -40,7 +40,15 @@ mkdir $T
cat > $T/init << '__EOF___'
#!/bin/sh
# Run in userspace a few milliseconds every second. This helps to
-# exercise the NO_HZ_FULL portions of RCU.
+# exercise the NO_HZ_FULL portions of RCU. Yes, there are 186 instances
+# of "a", which was empirically shown to give a nice multi-millisecond
+# burst of user-mode execution on a 2GHz CPU, as desired. Modern CPUs
+# will vary from a couple of milliseconds up to perhaps 100 milliseconds,
+# which is an acceptable range.
+#
+# Why not calibrate an exact delay? Because within this initrd, we
+# are restricted to Bourne-shell builtins, which as far as I know do not
+# provide any means of obtaining a fine-grained timestamp.
while :
do
q=
|