diff mbox series

[RFC] sched: starvation: Autocallibrate the timeout

Message ID 20240612091256.4931-1-chrubis@suse.cz
State Superseded
Headers show
Series [RFC] sched: starvation: Autocallibrate the timeout | expand

Commit Message

Cyril Hrubis June 12, 2024, 9:12 a.m. UTC 
Instead of hardcoding the values we attempt to measure the CPU speed and
set the timeout 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 timeout is about
double of the value of the actual test runtime and works fine, but we
need to make sure that the coeficient we divide the result from
callibrate works for small boards too. So please run the test on as many
machines as you can and report if we need to make the dividor smaller or
not.

CC: Steve <xufeifei1@oppo.com>
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
---
 .../kernel/sched/cfs-scheduler/starvation.c   | 40 +++++++++++++++++--
 1 file changed, 37 insertions(+), 3 deletions(-)

Comments

Petr Vorel June 12, 2024, 10:29 a.m. UTC | #1 
Hi all,

at least on ppc64le this results in TINFO: Updating max runtime to 0h 13m 17s
for test which runs 10 sec which is too much :(.

(aarch64, s390x have 3 min max runtime, x86_64 and i586 1 min)

Kind regards,
Petr
Cyril Hrubis June 12, 2024, 10:57 a.m. UTC | #2 
Hi!
> at least on ppc64le this results in TINFO: Updating max runtime to 0h 13m 17s
> for test which runs 10 sec which is too much :(.

Too bad. I want to avoid writing a callibration loops in assembly or
have the coeficients per architecture but I guess that it will be
inevitable.
Cyril Hrubis June 12, 2024, 11:21 a.m. UTC | #3 
Hi!
> > at least on ppc64le this results in TINFO: Updating max runtime to 0h 13m 17s
> > for test which runs 10 sec which is too much :(.
> 
> Too bad. I want to avoid writing a callibration loops in assembly or
> have the coeficients per architecture but I guess that it will be
> inevitable.

Can you try with v2 I'm sending right away?
diff mbox series

Patch

diff --git a/testcases/kernel/sched/cfs-scheduler/starvation.c b/testcases/kernel/sched/cfs-scheduler/starvation.c
index eb9fd6ff5..94175fdd1 100644
--- a/testcases/kernel/sched/cfs-scheduler/starvation.c
+++ b/testcases/kernel/sched/cfs-scheduler/starvation.c
@@ -21,11 +21,42 @@ 
 #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 100000000
+
+static int callibrate(void)
+{
+	volatile int counter;
+	struct timespec start, stop;
+	long long diff;
+
+	counter = CALLIBRATE_LOOPS;
+	do
+		counter--;
+	while (counter > 0);
+
+	SAFE_CLOCK_GETTIME(CLOCK_MONOTONIC_RAW, &start);
+
+	counter = CALLIBRATE_LOOPS;
+	do
+		counter--;
+	while (counter > 0);
+
+	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)
 {
@@ -59,8 +90,11 @@  static void setup(void)
 	if (tst_parse_long(str_loop, &loop, 1, LONG_MAX))
 		tst_brk(TBROK, "Invalid number of loop number '%s'", str_loop);
 
-	if (tst_parse_int(str_timeout, &timeout, 1, INT_MAX))
+	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);
 }