On 27/02/2026 08:41, Maxime Ripard wrote:
On Thu, Feb 26, 2026 at 12:42:39PM +0000, Tvrtko Ursulin wrote:
On 26/02/2026 10:56, Maxime Ripard wrote:
Hi Tvrtko,
On Tue, Feb 24, 2026 at 12:49:01PM +0000, Tvrtko Ursulin wrote:
On 24/02/2026 11:03, Maxime Ripard wrote:
Some DRM tests cross the 1s execution time threshold that defines a test
as slow. Let's flag them as such.
Curious that both did not trigger for me and I even run them under nested
qemu most of the time.
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/gpu/drm/scheduler/tests/tests_basic.c | 4 ++--
drivers/gpu/drm/tests/drm_buddy_test.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/tests/tests_basic.c
b/drivers/gpu/drm/scheduler/tests/tests_basic.c
index 82a41a456b0a..a5a5a35a87b0 100644
--- a/drivers/gpu/drm/scheduler/tests/tests_basic.c
+++ b/drivers/gpu/drm/scheduler/tests/tests_basic.c
@@ -419,11 +419,11 @@ static void drm_sched_change_priority(struct kunit *test)
drm_mock_sched_entity_free(entity[i]);
}
static struct kunit_case drm_sched_priority_tests[] = {
KUNIT_CASE(drm_sched_priorities),
- KUNIT_CASE(drm_sched_change_priority),
+ KUNIT_CASE_SLOW(drm_sched_change_priority),
This one deliberately aims to run for ~1s and I don't have an immediate idea
how it would go over 2s.
1s is the threshold for a slow test:
https://elixir.bootlin.com/linux/v6.19.3/source/lib/kunit/test.c#L365
It only warns about it if it crosses 2s, but if it's expected to take
1s, it should be flagged as such still.
I know, just curious which environment managed to trigger the warning.
Because I thought my test setup was the slowest one (nested virtualization -
qemu-system inside vmware).
I was running a cross-compiled arm64 system on my x86 machine, so
emulated. That being said, that one didn't cross the 2s threshold
either.
Good to know I wasn't missing something obvious in the test logic.
The tweaks I just sent change some tests from emitting 1000 1ms jobs to
only emitting 500 of them. Effectively targetting their runtime to
500ms, plus the hrtimer and worker item scheduling delays. Hopefully
even under emulation that is enough of a margin to never get over 1s,
let alone 2s of wall clock time.
Regards,
Tvrtko
Other tests did, and I used the occasion to flag every test that was
taking more than 1s.
{}
};
static struct kunit_suite drm_sched_priority = {
.name = "drm_sched_basic_priority_tests",
@@ -544,11 +544,11 @@ static void drm_sched_test_credits(struct kunit *test)
drm_mock_sched_entity_free(entity);
drm_mock_sched_fini(sched);
}
static struct kunit_case drm_sched_credits_tests[] = {
- KUNIT_CASE(drm_sched_test_credits),
+ KUNIT_CASE_SLOW(drm_sched_test_credits),
Same really.
Anyway, the scheduler parts LGTM and I can follow up trying to optimise
these two later.
For the scheduler:
Reviewed-by: Tvrtko Ursulin <[email protected]>
Thanks!
I have a patch already which makes those (and one more) test cases faster,
but I will wait sending it until you merge this one.
Ack, thanks!
Maxime
