[Skiboot] [RFC PATCH 01/10] core/test: run trace test last

[Stewart Smith]

Oliver O'Halloran <oohall at gmail.com> writes:
> The trace test takes the longest to run and is among the least useful
> of the tests. Run it last so we're not stuck waiting for it when
> some other test is more interesting.
>
> Signed-off-by: Oliver O'Halloran <oohall at gmail.com>
> ---
>  core/test/Makefile.check | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/core/test/Makefile.check b/core/test/Makefile.check
> index d3dd2600a230..cea72a94a297 100644
> --- a/core/test/Makefile.check
> +++ b/core/test/Makefile.check
> @@ -11,12 +11,14 @@ CORE_TEST := core/test/run-device \
>  	core/test/run-mem_region_reservations \
>  	core/test/run-mem_range_is_reserved \
>  	core/test/run-nvram-format \
> -	core/test/run-trace core/test/run-msg \
>  	core/test/run-pel \
>  	core/test/run-pool \
>  	core/test/run-time-utils \
>  	core/test/run-timebase \
> -	core/test/run-timer
> +	core/test/run-timer \
> +	core/test/run-msg \
> +	core/test/run-trace
> +# NB: The trace test takes forever, add new tests ABOVE run-trace

These aren't really an order to run things in... it's all up to make(1)
as to in what order they're run... and in my tests of this, it doesn't
change the execution time in any noticable way with either 4 or 20
hardware thread machine.

You shouldn't really have to wait, as 'make -j' does execute tests in
parallel.

The real issue with the trace test is how long it takes to run under
valgrind (35 seconds) versus non-valgrind (1 second).

(patch incoming that does this), if we detect running under valgrind and
just do fewer trace_add() calls, we do see a decent reduction in
execution time for 'make check' though. On my laptop, 12seconds (so 42s
down to 30s) for a quick 'make check'.

-- 
Stewart Smith
OPAL Architect, IBM.