public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: joe.liu@mediatek.com, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3] sched: starvation: Autocallibrate the timeout
Date: Mon, 29 Jul 2024 22:51:12 +0200	[thread overview]
Message-ID: <20240729205112.GA1287954@pevik> (raw)
In-Reply-To: <20240722145443.19104-1-chrubis@suse.cz>

Hi all,

> Instead of hardcoding the values we attempt to measure the CPU speed and
> set the runtime accordingly. Given that the difference in the duration
> of the test when the kernel is buggy is about 30x we do not have to have
> a precise callibration, just very rough estimate if we are running on a
> server or small ARM board would suffice.

> So we attempt to measure how long does a bussy loop take and base the
> default timeout on that. On x86_64 CPUs the resulting runtime seems to
> be between 2x and 10x of the actual runtime which seems to be in the
> required range.

> We also make sure to check the runtime at the end of the test because
> the failures could have been masked by a timeout multiplier, i.e. if you
> set LTP_TIMEOUT_MUL=10 the test would previously pass on a buggy kernel
> as well. The side efect is that we now get better PASS/FAIL messages as
> well.

> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---

> Changes in v3:

> - Increased the CALLIBRATE_LOOPS a bit, since some of the numbers
>   reported by the linaro lab had the runtime very close to the
>   calculated runtime.

Anders, Joe, can you please recheck?

> - Removed some curly braces, as suggested by pvorel

> - Added runtime check at the end of test to avoid false positives with
>   LTP_TIMEOUT_MUL.

Great!

LGTM.

Reviewed-by: Petr Vorel <pvorel@suse.cz>

Tested-by: Petr Vorel <pvorel@suse.cz>

Tested on Tumbleweed (kernel 6.10.1):

tst_tmpdir.c:316: TINFO: Using /tmp/LTP_starv8seE as tmpdir (tmpfs filesystem)
tst_test.c:1806: TINFO: LTP version: 20240524
tst_test.c:1650: TINFO: Timeout per run is 0h 00m 30s
starvation.c:71: TINFO: Setting affinity to CPU 0
tst_test.c:1658: TINFO: Updating max runtime to 0h 04m 00s
tst_test.c:1650: TINFO: Timeout per run is 0h 04m 30s
starvation.c:117: TPASS: wait_for_pid(child_pid) passed

=> test runs ~ 13s - 19s on aarch64, ppc64le and x86_64. Therefore not sure if
04m max runtime is good.

I'll have tomorrow some tests on various SLES versions.

Kind regards,
Petr

> .../kernel/sched/cfs-scheduler/starvation.c   | 41 +++++++++++++++++--
>  1 file changed, 38 insertions(+), 3 deletions(-)

> diff --git a/testcases/kernel/sched/cfs-scheduler/starvation.c b/testcases/kernel/sched/cfs-scheduler/starvation.c
> index 9ac388fdc..e707e0865 100644
> --- a/testcases/kernel/sched/cfs-scheduler/starvation.c
> +++ b/testcases/kernel/sched/cfs-scheduler/starvation.c
> @@ -21,11 +21,38 @@
>  #include <sched.h>

>  #include "tst_test.h"
> +#include "tst_safe_clocks.h"
> +#include "tst_timer.h"

>  static char *str_loop;
> -static long loop = 2000000;
> +static long loop = 1000000;
>  static char *str_timeout;
> -static int timeout = 240;
> +static int timeout;
> +
> +#define CALLIBRATE_LOOPS 120000000
> +
> +static int callibrate(void)
> +{
> +	int i;
> +	struct timespec start, stop;
> +	long long diff;
> +
> +	for (i = 0; i < CALLIBRATE_LOOPS; i++)
> +		__asm__ __volatile__ ("" : "+g" (i) : :);
> +
> +	SAFE_CLOCK_GETTIME(CLOCK_MONOTONIC_RAW, &start);
> +
> +	for (i = 0; i < CALLIBRATE_LOOPS; i++)
> +		__asm__ __volatile__ ("" : "+g" (i) : :);
> +
> +	SAFE_CLOCK_GETTIME(CLOCK_MONOTONIC_RAW, &stop);
> +
> +	diff = tst_timespec_diff_us(stop, start);
> +
> +	tst_res(TINFO, "CPU did %i loops in %llius", CALLIBRATE_LOOPS, diff);
> +
> +	return diff;
> +}

>  static int wait_for_pid(pid_t pid)
>  {
> @@ -78,6 +105,8 @@ static void setup(void)

>  	if (tst_parse_int(str_timeout, &timeout, 1, INT_MAX))
>  		tst_brk(TBROK, "Invalid number of timeout '%s'", str_timeout);
> +	else
> +		timeout = callibrate() / 1000;

>  	tst_set_max_runtime(timeout);
>  }
> @@ -114,7 +143,13 @@ static void do_test(void)
>  		sleep(1);

>  	SAFE_KILL(child_pid, SIGTERM);
> -	TST_EXP_PASS(wait_for_pid(child_pid));
> +
> +	if (!tst_remaining_runtime())
> +		tst_res(TFAIL, "Scheduller starvation reproduced.");
> +	else
> +		tst_res(TPASS, "Haven't reproduced scheduller starvation.");
> +
> +	TST_EXP_PASS_SILENT(wait_for_pid(child_pid));
>  }

>  static struct tst_test test = {

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2024-07-29 20:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-22 14:54 [LTP] [PATCH v3] sched: starvation: Autocallibrate the timeout Cyril Hrubis
2024-07-29 20:51 ` Petr Vorel [this message]
2024-07-30  7:08   ` Cyril Hrubis
2024-07-30  7:33     ` Petr Vorel
2024-07-30  8:49     ` Petr Vorel
2024-07-30  8:55       ` Cyril Hrubis
2024-08-01 12:15   ` Anders Roxell
2024-08-28 13:38 ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240729205112.GA1287954@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=joe.liu@mediatek.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox