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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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
>
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.