[PATCH] misc: kgdbts: Display progress of asynchronous tests

[PATCH] misc: kgdbts: Display progress of asynchronous tests

[Daniel Thompson]

kgdbts includes a couple of different "thrashing" style tests that
may have long runtimes (especially on simulated platforms) and which
run asynchronously. This is uncomfortable for interactive use and
makes setting timeouts tricky for automatic use.

Fix by providing a optional means to show progress during these tests.
Selecting 100 is somewhat arbitrary but it matches the step used on
the synchronous tests, is large enough to keep the call to printk
from invalidating the testing and is human enough to "feel about
right".

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
---
 drivers/misc/kgdbts.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 24108bfad889..6193270e7b3d 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -400,10 +400,14 @@ static void skip_back_repeat_test(char *arg)
 	int go_back = simple_strtol(arg, NULL, 10);

 	repeat_test--;
-	if (repeat_test <= 0)
+	if (repeat_test <= 0) {
 		ts.idx++;
-	else
+	} else {
+		if (repeat_test % 100 == 0)
+			v1printk("kgdbts:RUN ... %d remaining\n", repeat_test);
+
 		ts.idx -= go_back;
+	}
 	fill_get_buf(ts.tst[ts.idx].get);
 }

--
2.14.3

Re: [PATCH] misc: kgdbts: Display progress of asynchronous tests

[Jason Wessel]

On 12/12/2017 06:10 AM, Daniel Thompson wrote:
> kgdbts includes a couple of different "thrashing" style tests that
> may have long runtimes (especially on simulated platforms) and which
> run asynchronously. This is uncomfortable for interactive use and
> makes setting timeouts tricky for automatic use.


Do you know which test was specifically causing a problem?  It might not be documented anywhere but I had usually started a user space process which quickly created and deleted user space processes in order to make the kgdbts tests complete quickly.

I don't really see any issue with emitting a printk to indicate progress as it is debug only and test specific.  As you know printk's change timing.  If I had a dime for each time I had seen a problem go away when I started adding printk's I'd have at least a 50 cents.  :-)


Jason.

PS.  Added this to kgdb-next and I'll put in a request to get kgdb-next added back to the linux-next builder.

> 
> Fix by providing a optional means to show progress during these tests.
> Selecting 100 is somewhat arbitrary but it matches the step used on
> the synchronous tests, is large enough to keep the call to printk
> from invalidating the testing and is human enough to "feel about
> right".
> 
> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
> ---
>   drivers/misc/kgdbts.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
> index 24108bfad889..6193270e7b3d 100644
> --- a/drivers/misc/kgdbts.c
> +++ b/drivers/misc/kgdbts.c
> @@ -400,10 +400,14 @@ static void skip_back_repeat_test(char *arg)
>   	int go_back = simple_strtol(arg, NULL, 10);
> 
>   	repeat_test--;
> -	if (repeat_test <= 0)
> +	if (repeat_test <= 0) {
>   		ts.idx++;
> -	else
> +	} else {
> +		if (repeat_test % 100 == 0)
> +			v1printk("kgdbts:RUN ... %d remaining\n", repeat_test);
> +
>   		ts.idx -= go_back;
> +	}
>   	fill_get_buf(ts.tst[ts.idx].get);
>   }
> 
> --
> 2.14.3
> 

Re: [PATCH] misc: kgdbts: Display progress of asynchronous tests

[Daniel Thompson]

On 14/12/17 15:20, Jason Wessel wrote:
> On 12/12/2017 06:10 AM, Daniel Thompson wrote:
>> kgdbts includes a couple of different "thrashing" style tests that
>> may have long runtimes (especially on simulated platforms) and which
>> run asynchronously. This is uncomfortable for interactive use and
>> makes setting timeouts tricky for automatic use.
> 
> 
> Do you know which test was specifically causing a problem?  It might not 
> be documented anywhere but I had usually started a user space process 
> which quickly created and deleted user space processes in order to make 
> the kgdbts tests complete quickly.

kgdbts=V1S10000 was bumping into 30 second timeouts.

IIRC this was simulating arm hardware on a fairly powerful x86 host 
machine. You can see the temporary workaround I used here:
https://github.com/daniel-thompson/kcontest/blob/master/tests/test_kgdb_selftest.py#L114

I decided this workaround was insufficient however since it would be 
rather brittle if I wanted to move to slower (more power efficient) 
hardware.


> I don't really see any issue with emitting a printk to indicate progress 
> as it is debug only and test specific.  As you know printk's change 
> timing.  If I had a dime for each time I had seen a problem go away when 
> I started adding printk's I'd have at least a 50 cents.  :-)

Agree about the interference.

I worked on the basis that these are thrashing style tests so providing 
there is a human perceivable gap between console messages (i.e. we are 
not "wasting" a CPU on an SMP system by having it in printk all the 
time) then perturbing the timing with printk() could even be beneficial.


Daniel.