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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.