Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Josh Triplett]

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?)

Please also consider calibrating the delay loop as you do in the C code.

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Paul E. McKenney]

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@linux.ibm.com>
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@joshtriplett.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>

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=

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Josh Triplett]

On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> 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.  :-/

Sure, and I'm not suggesting adding commands to the initrd, hence my
mention of "If there's no better way".

> So how about the following patch, which attempts to explain the situation?

That would help, but please also consider consolidating with something
like a10="a a a a a a a a a a" to make it more readable (and perhaps
rounding up to 200 for simplicity).

- Josh

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Paul E. McKenney]

On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > 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.  :-/
> 
> Sure, and I'm not suggesting adding commands to the initrd, hence my
> mention of "If there's no better way".
> 
> > So how about the following patch, which attempts to explain the situation?
> 
> That would help, but please also consider consolidating with something
> like a10="a a a a a a a a a a" to make it more readable (and perhaps
> rounding up to 200 for simplicity).

How about powers of four and one factor of three for 192, as shown below?

							Thanx, Paul

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

commit 4f8f751961b536f77c8f82394963e8e2d26efd84
Author: Paul E. McKenney <paulmck@linux.ibm.com>
Date:   Tue Dec 4 14:59:12 2018 -0800

    torture: Explain and simplify odd "for" loop in mkinitrd.sh
    
    Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
    adds a shell comment to present the answer to these mysteries.  It also
    uses a series of factor-of-four Bourne-shell assignments to make it
    easy to see how many instances there are, replacing the earlier wall of
    'a' characters.
    
    Reported-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>

diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
index da298394daa2..ff69190604ea 100755
--- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
+++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
@@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
+
+a4="a a a a"
+a16="$a4 $a4 $a4 $a4"
+a64="$a8 $a8 $a8 $a8"
+a192="$a64 $a64 $a64"
 while :
 do
 	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
+	for i in $a192
 	do
 		q="$q $i"
 	done

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Josh Triplett]

On Wed, Dec 05, 2018 at 04:08:09PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > > 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.  :-/
> > 
> > Sure, and I'm not suggesting adding commands to the initrd, hence my
> > mention of "If there's no better way".
> > 
> > > So how about the following patch, which attempts to explain the situation?
> > 
> > That would help, but please also consider consolidating with something
> > like a10="a a a a a a a a a a" to make it more readable (and perhaps
> > rounding up to 200 for simplicity).
> 
> How about powers of four and one factor of three for 192, as shown below?

Perfect, thanks. That's much better.

Reviewed-by: Josh Triplett <josh@joshtriplett.org>

> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 4f8f751961b536f77c8f82394963e8e2d26efd84
> Author: Paul E. McKenney <paulmck@linux.ibm.com>
> Date:   Tue Dec 4 14:59:12 2018 -0800
> 
>     torture: Explain and simplify odd "for" loop in mkinitrd.sh
>     
>     Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
>     adds a shell comment to present the answer to these mysteries.  It also
>     uses a series of factor-of-four Bourne-shell assignments to make it
>     easy to see how many instances there are, replacing the earlier wall of
>     'a' characters.
>     
>     Reported-by: Josh Triplett <josh@joshtriplett.org>
>     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> 
> diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> index da298394daa2..ff69190604ea 100755
> --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> @@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
> +
> +a4="a a a a"
> +a16="$a4 $a4 $a4 $a4"
> +a64="$a8 $a8 $a8 $a8"
> +a192="$a64 $a64 $a64"
>  while :
>  do
>  	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
> +	for i in $a192
>  	do
>  		q="$q $i"
>  	done
> 

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Andrea Parri]

> commit 4f8f751961b536f77c8f82394963e8e2d26efd84
> Author: Paul E. McKenney <paulmck@linux.ibm.com>
> Date:   Tue Dec 4 14:59:12 2018 -0800
> 
>     torture: Explain and simplify odd "for" loop in mkinitrd.sh
>     
>     Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
>     adds a shell comment to present the answer to these mysteries.  It also
>     uses a series of factor-of-four Bourne-shell assignments to make it
>     easy to see how many instances there are, replacing the earlier wall of
>     'a' characters.
>     
>     Reported-by: Josh Triplett <josh@joshtriplett.org>
>     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> 
> diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> index da298394daa2..ff69190604ea 100755
> --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> @@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
> +
> +a4="a a a a"
> +a16="$a4 $a4 $a4 $a4"
> +a64="$a8 $a8 $a8 $a8"

Mmh, are you sure you don't want s/a8/a16/ here? ;-)

  Andrea


> +a192="$a64 $a64 $a64"
>  while :
>  do
>  	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
> +	for i in $a192
>  	do
>  		q="$q $i"
>  	done
> 

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Josh Triplett]

On Thu, Dec 06, 2018 at 01:51:47AM +0100, Andrea Parri wrote:
> > commit 4f8f751961b536f77c8f82394963e8e2d26efd84
> > Author: Paul E. McKenney <paulmck@linux.ibm.com>
> > Date:   Tue Dec 4 14:59:12 2018 -0800
> > 
> >     torture: Explain and simplify odd "for" loop in mkinitrd.sh
> >     
> >     Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
> >     adds a shell comment to present the answer to these mysteries.  It also
> >     uses a series of factor-of-four Bourne-shell assignments to make it
> >     easy to see how many instances there are, replacing the earlier wall of
> >     'a' characters.
> >     
> >     Reported-by: Josh Triplett <josh@joshtriplett.org>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > 
> > diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > index da298394daa2..ff69190604ea 100755
> > --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > @@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
> > +
> > +a4="a a a a"
> > +a16="$a4 $a4 $a4 $a4"
> > +a64="$a8 $a8 $a8 $a8"
> 
> Mmh, are you sure you don't want s/a8/a16/ here? ;-)

... *facepalm*

Good catch.

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Paul E. McKenney]

On Wed, Dec 05, 2018 at 04:27:38PM -0800, Josh Triplett wrote:
> On Wed, Dec 05, 2018 at 04:08:09PM -0800, Paul E. McKenney wrote:
> > On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> > > On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > > > 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.  :-/
> > > 
> > > Sure, and I'm not suggesting adding commands to the initrd, hence my
> > > mention of "If there's no better way".
> > > 
> > > > So how about the following patch, which attempts to explain the situation?
> > > 
> > > That would help, but please also consider consolidating with something
> > > like a10="a a a a a a a a a a" to make it more readable (and perhaps
> > > rounding up to 200 for simplicity).
> > 
> > How about powers of four and one factor of three for 192, as shown below?
> 
> Perfect, thanks. That's much better.
> 
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>

Applied, thank you!

							Thanx, Paul

> > ------------------------------------------------------------------------
> > 
> > commit 4f8f751961b536f77c8f82394963e8e2d26efd84
> > Author: Paul E. McKenney <paulmck@linux.ibm.com>
> > Date:   Tue Dec 4 14:59:12 2018 -0800
> > 
> >     torture: Explain and simplify odd "for" loop in mkinitrd.sh
> >     
> >     Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
> >     adds a shell comment to present the answer to these mysteries.  It also
> >     uses a series of factor-of-four Bourne-shell assignments to make it
> >     easy to see how many instances there are, replacing the earlier wall of
> >     'a' characters.
> >     
> >     Reported-by: Josh Triplett <josh@joshtriplett.org>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > 
> > diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > index da298394daa2..ff69190604ea 100755
> > --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > @@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
> > +
> > +a4="a a a a"
> > +a16="$a4 $a4 $a4 $a4"
> > +a64="$a8 $a8 $a8 $a8"
> > +a192="$a64 $a64 $a64"
> >  while :
> >  do
> >  	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
> > +	for i in $a192
> >  	do
> >  		q="$q $i"
> >  	done
> > 
> 

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Paul E. McKenney]

On Thu, Dec 06, 2018 at 01:51:47AM +0100, Andrea Parri wrote:
> > commit 4f8f751961b536f77c8f82394963e8e2d26efd84
> > Author: Paul E. McKenney <paulmck@linux.ibm.com>
> > Date:   Tue Dec 4 14:59:12 2018 -0800
> > 
> >     torture: Explain and simplify odd "for" loop in mkinitrd.sh
> >     
> >     Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
> >     adds a shell comment to present the answer to these mysteries.  It also
> >     uses a series of factor-of-four Bourne-shell assignments to make it
> >     easy to see how many instances there are, replacing the earlier wall of
> >     'a' characters.
> >     
> >     Reported-by: Josh Triplett <josh@joshtriplett.org>
> >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > 
> > diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > index da298394daa2..ff69190604ea 100755
> > --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > @@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
> > +
> > +a4="a a a a"
> > +a16="$a4 $a4 $a4 $a4"
> > +a64="$a8 $a8 $a8 $a8"
> 
> Mmh, are you sure you don't want s/a8/a16/ here? ;-)

Indeed I do!  How about the following?

							Thanx, Paul

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

commit 94cae122408cdc55470360868a1a4b8f160e576d
Author: Paul E. McKenney <paulmck@linux.ibm.com>
Date:   Tue Dec 4 14:59:12 2018 -0800

    torture: Explain and simplify odd "for" loop in mkinitrd.sh
    
    Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
    adds a shell comment to present the answer to these mysteries.  It also
    uses a series of factor-of-four Bourne-shell assignments to make it
    easy to see how many instances there are, replacing the earlier wall of
    'a' characters.
    
    Reported-by: Josh Triplett <josh@joshtriplett.org>
    Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
    Reviewed-by: Josh Triplett <josh@joshtriplett.org>
    [ paulmck: Fix wrong-variable bugs noted by Andrea Parri. ]

diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
index da298394daa2..e79eb35c41e2 100755
--- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
+++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
@@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
+
+a4="a a a a"
+a16="$a4 $a4 $a4 $a4"
+a64="$a16 $a16 $a16 $a16"
+a192="$a64 $a64 $a64"
 while :
 do
 	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
+	for i in $a192
 	do
 		q="$q $i"
 	done

Re: [tip:core/rcu] rcutorture: Make initrd/init execute in userspace

[Paul E. McKenney]

On Wed, Dec 05, 2018 at 04:58:27PM -0800, Josh Triplett wrote:
> On Thu, Dec 06, 2018 at 01:51:47AM +0100, Andrea Parri wrote:
> > > commit 4f8f751961b536f77c8f82394963e8e2d26efd84
> > > Author: Paul E. McKenney <paulmck@linux.ibm.com>
> > > Date:   Tue Dec 4 14:59:12 2018 -0800
> > > 
> > >     torture: Explain and simplify odd "for" loop in mkinitrd.sh
> > >     
> > >     Why a Bourne-shell "for" loop?  And why 192 instances of "a"?  This commit
> > >     adds a shell comment to present the answer to these mysteries.  It also
> > >     uses a series of factor-of-four Bourne-shell assignments to make it
> > >     easy to see how many instances there are, replacing the earlier wall of
> > >     'a' characters.
> > >     
> > >     Reported-by: Josh Triplett <josh@joshtriplett.org>
> > >     Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > > 
> > > diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > > index da298394daa2..ff69190604ea 100755
> > > --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > > +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> > > @@ -40,17 +40,24 @@ 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.  The 192 instances of "a" 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.
> > > +
> > > +a4="a a a a"
> > > +a16="$a4 $a4 $a4 $a4"
> > > +a64="$a8 $a8 $a8 $a8"
> > 
> > Mmh, are you sure you don't want s/a8/a16/ here? ;-)
> 
> ... *facepalm*

Yeah, me as well...

> Good catch.

Thank you both!!!

							Thanx, Paul