[LTP] [PATCH v2] sched: starvation: Autocallibrate the timeout

[Cyril Hrubis]

Hi!
> > 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.
> 
> While applying this new patch, the test result of 32bit kernel is still failed. Please refers following log:
> 
> external/ltp/lib/tst_test.c:1690: TINFO: LTP version: 20230929
> external/ltp/lib/tst_test.c:1576: TINFO: Timeout per run is 0h 00m 30s
> external/ltp/testcases/kernel/sched/cfs-scheduler/starvation.c:90: TPASS: sched_setaffinity(0, sizeof(mask), &mask) returned 0
> external/ltp/testcases/kernel/sched/cfs-scheduler/starvation.c:58: TINFO: CPU did 100000000 loops in 198306us
> external/ltp/testcases/kernel/sched/cfs-scheduler/starvation.c:99: TINFO: cal timeout: 198
> external/ltp/lib/tst_test.c:1583: TINFO: Updating max runtime to 0h 03m 18s
> external/ltp/lib/tst_test.c:1576: TINFO: Timeout per run is 0h 03m 48s
> Test timeouted, sending SIGKILL!
> 
> After using "time ./starvation" to check the timecost, we can see the timecost is about 26 mins and 48 seconds

This is really strange. I tested the code on RPi Zero with 32bit BCM2835
where the CPU is even slower and runtime limit is set to about 5
minutes, yet the test finished in a minute. That's with resonably recent
kernel 6.1 though.

What kernel version do you use?

Do you run LTP with background tasks to keep the CPU bussy?

Do you have any custom patches for kernel scheduller applied?

It really looks like something unexpected is happening at your end.

-- 
Cyril Hrubis
chrubis@suse.cz