[PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[David Gow]

The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
total_us, and fail if it's exceeded. However, on systems with
CONFIG_HZ < 250, this tends to fail.

As it's possible to configure many architectures to use 100 Hz (and some,
such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the test
doesn't fail on these configurations.

Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
Signed-off-by: David Gow <david@davidgow.net>
---

This failure showed up on UML when testing the addition of CONFIG_DRM to
the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
(or at least skipped/disabled) on these broken configurations so that the
alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
other than UML, but fixing them all is ideal if we can manage it.)

If you'd rather a different implementation / magic number, let me know.
I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
on this machine.

Thanks,
-- David

[1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-c5c0f18fc7b0@kernel.org/
---
 drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
index 285546a2218f..02c83b5c2189 100644
--- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
+++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
@@ -13,6 +13,13 @@
  * logic.
  */
 
+/* We need a more generous timeout when CONFIG_HZ=100. */
+#if CONFIG_HZ < 250
+#define TIMEOUT_MULTIPLIER 15
+#else
+#define TIMEOUT_MULTIPLIER 5
+#endif
+
 static int drm_sched_scheduler_init(struct kunit *test)
 {
 	struct drm_mock_scheduler *sched;
@@ -88,7 +95,7 @@ static void drm_sched_scheduler_queue_overhead(struct kunit *test)
 
 	/* Wait with a safe margin to avoid every failing. */
 	done = drm_mock_sched_job_wait_finished(job,
-						usecs_to_jiffies(total_us) * 5);
+						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
 	end = ktime_get();
 	KUNIT_ASSERT_TRUE(test, done);
 
@@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct kunit *test)
 
 	/* Wait with a safe margin to avoid every failing. */
 	done = drm_mock_sched_job_wait_finished(job,
-						usecs_to_jiffies(total_us) * 5);
+						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
 	end = ktime_get();
 	KUNIT_ASSERT_TRUE(test, done);
 
-- 
2.55.0

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[Tvrtko Ursulin]

On 13/09/2026 09:41, David Gow wrote:
> The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
> total_us, and fail if it's exceeded. However, on systems with
> CONFIG_HZ < 250, this tends to fail.

Systems plural or just UML? I suppose if no hrtimer support and low HZ 
it is plausible since executing the tests needs 1000 x 1ms hrtimer 
callbacks to fire.

Anyway, increasing the tolerance is okay-ish, with the -ish part being 
that it would be even better to skip if test could know before hand on a 
particular system it would be uselessly slow. Hence I am curious whether 
it is just UML or you could point me to other specific platforms/kconfig 
combinations where you saw it fail. In which case maybe we can come up 
with a skip criteria.

Regards,

Tvrtko

> As it's possible to configure many architectures to use 100 Hz (and some,
> such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the test
> doesn't fail on these configurations.
> 
> Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
> Signed-off-by: David Gow <david@davidgow.net>
> ---
> 
> This failure showed up on UML when testing the addition of CONFIG_DRM to
> the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
> (or at least skipped/disabled) on these broken configurations so that the
> alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
> other than UML, but fixing them all is ideal if we can manage it.)
> 
> If you'd rather a different implementation / magic number, let me know.
> I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
> all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
> on this machine.
> 
> Thanks,
> -- David
> 
> [1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-c5c0f18fc7b0@kernel.org/
> ---
>   drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
>   1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
> index 285546a2218f..02c83b5c2189 100644
> --- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
> @@ -13,6 +13,13 @@
>    * logic.
>    */
>   
> +/* We need a more generous timeout when CONFIG_HZ=100. */
> +#if CONFIG_HZ < 250
> +#define TIMEOUT_MULTIPLIER 15
> +#else
> +#define TIMEOUT_MULTIPLIER 5
> +#endif
> +
>   static int drm_sched_scheduler_init(struct kunit *test)
>   {
>   	struct drm_mock_scheduler *sched;
> @@ -88,7 +95,7 @@ static void drm_sched_scheduler_queue_overhead(struct kunit *test)
>   
>   	/* Wait with a safe margin to avoid every failing. */
>   	done = drm_mock_sched_job_wait_finished(job,
> -						usecs_to_jiffies(total_us) * 5);
> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>   	end = ktime_get();
>   	KUNIT_ASSERT_TRUE(test, done);
>   
> @@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct kunit *test)
>   
>   	/* Wait with a safe margin to avoid every failing. */
>   	done = drm_mock_sched_job_wait_finished(job,
> -						usecs_to_jiffies(total_us) * 5);
> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>   	end = ktime_get();
>   	KUNIT_ASSERT_TRUE(test, done);
>   

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[David Gow]

Le 14/09/2026 à 4:49 PM, Tvrtko Ursulin a écrit :
> 
> On 13/09/2026 09:41, David Gow wrote:
>> The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
>> total_us, and fail if it's exceeded. However, on systems with
>> CONFIG_HZ < 250, this tends to fail.
> 
> Systems plural or just UML? I suppose if no hrtimer support and low HZ
> it is plausible since executing the tests needs 1000 x 1ms hrtimer
> callbacks to fire.

UML is the most important of the ones I tested (as it doesn't have a way
to increase HZ, though it did pass if I manually forced CONFIG_HZ=1000),
but even x86/x86_64 will trigger this if CONFIG_HZ_100=y.

For example, I can reproduce it with:
./tools/testing/kunit/kunit.py run --arch x86_64 --kconfig_add CONFIG_DRM=y --kconfig_add CONFIG_HZ_100=y drm_sched_scheduler_overhead_tests

> 
> Anyway, increasing the tolerance is okay-ish, with the -ish part being
> that it would be even better to skip if test could know before hand on a
> particular system it would be uselessly slow. Hence I am curious whether
> it is just UML or you could point me to other specific platforms/kconfig
> combinations where you saw it fail. In which case maybe we can come up
> with a skip criteria.

I saw it passing relatively consistently on x86 (under qemu) with
CONFIG_HZ=250, and failing consistently on everything with
CONFIG_HZ=100.
I don't think it'd be a problem to either have the test depend
on CONFIG_HZ >= 250 or use that as criteria to skip the test
altogether.

I'm happy to send out a v2 of this patch which just uses the same
criteria (CONFIG_HZ < 250) to just skip the test if you'd prefer.

Cheers,
-- David

> 
> Regards,
> 
> Tvrtko
> 
>> As it's possible to configure many architectures to use 100 Hz (and some,
>> such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the
>> test
>> doesn't fail on these configurations.
>>
>> Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
>> Signed-off-by: David Gow <david@davidgow.net>
>> ---
>>
>> This failure showed up on UML when testing the addition of CONFIG_DRM to
>> the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
>> (or at least skipped/disabled) on these broken configurations so that the
>> alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
>> other than UML, but fixing them all is ideal if we can manage it.)
>>
>> If you'd rather a different implementation / magic number, let me know.
>> I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
>> all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
>> on this machine.
>>
>> Thanks,
>> -- David
>>
>> [1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-
>> c5c0f18fc7b0@kernel.org/
>> ---
>>   drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
>>   1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/
>> drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> index 285546a2218f..02c83b5c2189 100644
>> --- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> @@ -13,6 +13,13 @@
>>    * logic.
>>    */
>>   +/* We need a more generous timeout when CONFIG_HZ=100. */
>> +#if CONFIG_HZ < 250
>> +#define TIMEOUT_MULTIPLIER 15
>> +#else
>> +#define TIMEOUT_MULTIPLIER 5
>> +#endif
>> +
>>   static int drm_sched_scheduler_init(struct kunit *test)
>>   {
>>       struct drm_mock_scheduler *sched;
>> @@ -88,7 +95,7 @@ static void
>> drm_sched_scheduler_queue_overhead(struct kunit *test)
>>         /* Wait with a safe margin to avoid every failing. */
>>       done = drm_mock_sched_job_wait_finished(job,
>> -                        usecs_to_jiffies(total_us) * 5);
>> +                        usecs_to_jiffies(total_us) *
>> TIMEOUT_MULTIPLIER);
>>       end = ktime_get();
>>       KUNIT_ASSERT_TRUE(test, done);
>>   @@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct
>> kunit *test)
>>         /* Wait with a safe margin to avoid every failing. */
>>       done = drm_mock_sched_job_wait_finished(job,
>> -                        usecs_to_jiffies(total_us) * 5);
>> +                        usecs_to_jiffies(total_us) *
>> TIMEOUT_MULTIPLIER);
>>       end = ktime_get();
>>       KUNIT_ASSERT_TRUE(test, done);
>>   
> 

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[Tvrtko Ursulin]

On 14/09/2026 11:06, David Gow wrote:
> Le 14/09/2026 à 4:49 PM, Tvrtko Ursulin a écrit :
>>
>> On 13/09/2026 09:41, David Gow wrote:
>>> The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
>>> total_us, and fail if it's exceeded. However, on systems with
>>> CONFIG_HZ < 250, this tends to fail.
>>
>> Systems plural or just UML? I suppose if no hrtimer support and low HZ
>> it is plausible since executing the tests needs 1000 x 1ms hrtimer
>> callbacks to fire.
> 
> UML is the most important of the ones I tested (as it doesn't have a way
> to increase HZ, though it did pass if I manually forced CONFIG_HZ=1000),
> but even x86/x86_64 will trigger this if CONFIG_HZ_100=y.
> 
> For example, I can reproduce it with:
> ./tools/testing/kunit/kunit.py run --arch x86_64 --kconfig_add CONFIG_DRM=y --kconfig_add CONFIG_HZ_100=y drm_sched_scheduler_overhead_tests

Right, I even developed the tests with that setup, just under arm64 and 
the default HZ=250.
  >> Anyway, increasing the tolerance is okay-ish, with the -ish part being
>> that it would be even better to skip if test could know before hand on a
>> particular system it would be uselessly slow. Hence I am curious whether
>> it is just UML or you could point me to other specific platforms/kconfig
>> combinations where you saw it fail. In which case maybe we can come up
>> with a skip criteria.
> 
> I saw it passing relatively consistently on x86 (under qemu) with
> CONFIG_HZ=250, and failing consistently on everything with
> CONFIG_HZ=100.
> I don't think it'd be a problem to either have the test depend
> on CONFIG_HZ >= 250 or use that as criteria to skip the test
> altogether.
> 
> I'm happy to send out a v2 of this patch which just uses the same
> criteria (CONFIG_HZ < 250) to just skip the test if you'd prefer.

I suspect the real condition would be HZ < 250 && 
something-like-!hrtimer_highres_enabled, but as the latter is not 
exported for modules I have no smart ideas. It's not a loss really to 
skip the scheduling quality tests on more platforms than strictly 
required so I'd say lets go with that.

Regards,

Tvrtko

>>> As it's possible to configure many architectures to use 100 Hz (and some,
>>> such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the
>>> test
>>> doesn't fail on these configurations.
>>>
>>> Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
>>> Signed-off-by: David Gow <david@davidgow.net>
>>> ---
>>>
>>> This failure showed up on UML when testing the addition of CONFIG_DRM to
>>> the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
>>> (or at least skipped/disabled) on these broken configurations so that the
>>> alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
>>> other than UML, but fixing them all is ideal if we can manage it.)
>>>
>>> If you'd rather a different implementation / magic number, let me know.
>>> I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
>>> all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
>>> on this machine.
>>>
>>> Thanks,
>>> -- David
>>>
>>> [1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-
>>> c5c0f18fc7b0@kernel.org/
>>> ---
>>>    drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
>>>    1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/
>>> drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>>> index 285546a2218f..02c83b5c2189 100644
>>> --- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>>> +++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>>> @@ -13,6 +13,13 @@
>>>     * logic.
>>>     */
>>>    +/* We need a more generous timeout when CONFIG_HZ=100. */
>>> +#if CONFIG_HZ < 250
>>> +#define TIMEOUT_MULTIPLIER 15
>>> +#else
>>> +#define TIMEOUT_MULTIPLIER 5
>>> +#endif
>>> +
>>>    static int drm_sched_scheduler_init(struct kunit *test)
>>>    {
>>>        struct drm_mock_scheduler *sched;
>>> @@ -88,7 +95,7 @@ static void
>>> drm_sched_scheduler_queue_overhead(struct kunit *test)
>>>          /* Wait with a safe margin to avoid every failing. */
>>>        done = drm_mock_sched_job_wait_finished(job,
>>> -                        usecs_to_jiffies(total_us) * 5);
>>> +                        usecs_to_jiffies(total_us) *
>>> TIMEOUT_MULTIPLIER);
>>>        end = ktime_get();
>>>        KUNIT_ASSERT_TRUE(test, done);
>>>    @@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct
>>> kunit *test)
>>>          /* Wait with a safe margin to avoid every failing. */
>>>        done = drm_mock_sched_job_wait_finished(job,
>>> -                        usecs_to_jiffies(total_us) * 5);
>>> +                        usecs_to_jiffies(total_us) *
>>> TIMEOUT_MULTIPLIER);
>>>        end = ktime_get();
>>>        KUNIT_ASSERT_TRUE(test, done);
>>>    
>>
> 

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[Philipp Stanner]

On Mon, 2026-09-14 at 12:21 +0100, Tvrtko Ursulin wrote:
> It's not a loss really to
> skip the scheduling quality tests on more platforms than strictly 
> required so I'd say lets go with that.

Does that mean you agree with my idea of having two options for
building the tests, one for sanity and one for performance-ish things?


P.

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[Tvrtko Ursulin]

On 14/09/2026 12:48, Philipp Stanner wrote:
> On Mon, 2026-09-14 at 12:21 +0100, Tvrtko Ursulin wrote:
>> It's not a loss really to
>> skip the scheduling quality tests on more platforms than strictly
>> required so I'd say lets go with that.
> 
> Does that mean you agree with my idea of having two options for
> building the tests, one for sanity and one for performance-ish things?

A new kconfig? Makes sense.
Regards,

Tvrtko

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[David Gow]

Le 14/09/2026 à 8:12 PM, Tvrtko Ursulin a écrit :
> 
> On 14/09/2026 12:48, Philipp Stanner wrote:
>> On Mon, 2026-09-14 at 12:21 +0100, Tvrtko Ursulin wrote:
>>> It's not a loss really to
>>> skip the scheduling quality tests on more platforms than strictly
>>> required so I'd say lets go with that.
>>
>> Does that mean you agree with my idea of having two options for
>> building the tests, one for sanity and one for performance-ish things?
> 
> A new kconfig? Makes sense.

This sounds good to me (particularly if it's likely to extend to more
than just the two tests).

If they're behind a separate kconfig, there's no need on my end for
these tests to support UML or other HZ=100 setups (though I don't think
it's a _bad_ idea to have a more friendly skip or error in that case if
you'd particularly like one).

Thanks very much,
-- David

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[Philipp Stanner]

+Cc Marco

On Sun, 2026-09-13 at 16:41 +0800, David Gow wrote:
> The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
> total_us, and fail if it's exceeded. However, on systems with
> CONFIG_HZ < 250, this tends to fail.
> 
> As it's possible to configure many architectures to use 100 Hz (and some,
> such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the test
> doesn't fail on these configurations.
> 
> Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
> Signed-off-by: David Gow <david@davidgow.net>
> ---
> 
> This failure showed up on UML when testing the addition of CONFIG_DRM to
> the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
> (or at least skipped/disabled) on these broken configurations so that the
> alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
> other than UML, but fixing them all is ideal if we can manage it.)
> 
> If you'd rather a different implementation / magic number, let me know.
> I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
> all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
> on this machine.
> 
> Thanks,
> -- David

Thx for the patch. Where are you running the tests and what for, is it
a CI or other test system?


So one thing about the unit tests is that they were originally not so
much intended for being run on all sorts of CIs, but as a development
tool for the drm_sched devs to have something to move forward with.
That's in part why they contain "scheduling quality tests".

That caused some raised eyebrows already because people run these
lengthy tests in CIs.

Maybe what we actually should have is a split of the test suite into
two parts, where one part covers basic sanity, and the other measures
scheduling behavior. The former could then be run by CI folks, the
latter explicitly be discouraged from being run by anyone who is not a
drm_sched-developer.


P.

> 
> [1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-c5c0f18fc7b0@kernel.org/
> ---
>  drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
> index 285546a2218f..02c83b5c2189 100644
> --- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
> @@ -13,6 +13,13 @@
>   * logic.
>   */
>  
> +/* We need a more generous timeout when CONFIG_HZ=100. */
> +#if CONFIG_HZ < 250
> +#define TIMEOUT_MULTIPLIER 15
> +#else
> +#define TIMEOUT_MULTIPLIER 5
> +#endif
> +
>  static int drm_sched_scheduler_init(struct kunit *test)
>  {
>  	struct drm_mock_scheduler *sched;
> @@ -88,7 +95,7 @@ static void drm_sched_scheduler_queue_overhead(struct kunit *test)
>  
>  	/* Wait with a safe margin to avoid every failing. */
>  	done = drm_mock_sched_job_wait_finished(job,
> -						usecs_to_jiffies(total_us) * 5);
> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>  	end = ktime_get();
>  	KUNIT_ASSERT_TRUE(test, done);
>  
> @@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct kunit *test)
>  
>  	/* Wait with a safe margin to avoid every failing. */
>  	done = drm_mock_sched_job_wait_finished(job,
> -						usecs_to_jiffies(total_us) * 5);
> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>  	end = ktime_get();
>  	KUNIT_ASSERT_TRUE(test, done);
>  
		

Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[David Gow]

Le 14/09/2026 à 5:03 PM, Philipp Stanner a écrit :
> +Cc Marco
> 
> On Sun, 2026-09-13 at 16:41 +0800, David Gow wrote:
>> The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
>> total_us, and fail if it's exceeded. However, on systems with
>> CONFIG_HZ < 250, this tends to fail.
>>
>> As it's possible to configure many architectures to use 100 Hz (and some,
>> such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the test
>> doesn't fail on these configurations.
>>
>> Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
>> Signed-off-by: David Gow <david@davidgow.net>
>> ---
>>
>> This failure showed up on UML when testing the addition of CONFIG_DRM to
>> the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
>> (or at least skipped/disabled) on these broken configurations so that the
>> alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
>> other than UML, but fixing them all is ideal if we can manage it.)
>>
>> If you'd rather a different implementation / magic number, let me know.
>> I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
>> all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
>> on this machine.
>>
>> Thanks,
>> -- David
> 
> Thx for the patch. Where are you running the tests and what for, is it
> a CI or other test system?
> 

Yeah, this is generally for KUnit in CI (and, in my case, to make sure
changes to KUnit itself don't regress other tests). But KUnit tests are
also run in several different CI systems, and now on linux-next as well.

In particular, this has been caught up whilst testing adding
CONFIG_DRM=y to the KUnit 'alltests' config, which is used to get a
config which includes as many tests as possible. This is finding some
real issues, so I think it is worthwhile in general.

> 
> So one thing about the unit tests is that they were originally not so
> much intended for being run on all sorts of CIs, but as a development
> tool for the drm_sched devs to have something to move forward with.
> That's in part why they contain "scheduling quality tests".
> 
> That caused some raised eyebrows already because people run these
> lengthy tests in CIs.

Yeah, finding the distinction between KUnit as a useful tool/framework
for writing tests and KUnit as a suite of tests that should be run
automatically is a bit tricky.

Ultimately, it's a judgement call if the benefit of having the test run
more widely (potentially uncovering real issues, or discovering issues
earlier in, e.g, linux-next merges) is worth the effort of making the
test suitably robust against all of the different environments it runs in.

> Maybe what we actually should have is a split of the test suite into
> two parts, where one part covers basic sanity, and the other measures
> scheduling behavior. The former could then be run by CI folks, the
> latter explicitly be discouraged from being run by anyone who is not a
> drm_sched-developer.
> 

That definitely can be done. As-is, the way this is currently handled is
though CONFIG_KUNIT_ALL_TESTS, and through .kunitconfig files.

If you don't want tests to be caught up in automatic systems (other, I
guess, than your own), then removing the 'default KUNIT_ALL_TESTS' (and
'if !KUNIT_ALL_TESTS' from the DRM_SCHED_KUNIT_TEST Kconfig entry is the
simplest way to do it. You could then set CONFIG_DRM_SCHED_KUNIT_TEST=y
(either via a .kunitconfig file or some other means) to run them whilst
doing drm scheduler development in particular.

And, of course, splitting suites up or skipping tests if certain
prerequisites aren't met are both options for keeping tests in the more
general CI pool if you'd like.

Cheers,
-- David

> 
> P.
> 
>>
>> [1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-c5c0f18fc7b0@kernel.org/
>> ---
>>  drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> index 285546a2218f..02c83b5c2189 100644
>> --- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> @@ -13,6 +13,13 @@
>>   * logic.
>>   */
>>  
>> +/* We need a more generous timeout when CONFIG_HZ=100. */
>> +#if CONFIG_HZ < 250
>> +#define TIMEOUT_MULTIPLIER 15
>> +#else
>> +#define TIMEOUT_MULTIPLIER 5
>> +#endif
>> +
>>  static int drm_sched_scheduler_init(struct kunit *test)
>>  {
>>  	struct drm_mock_scheduler *sched;
>> @@ -88,7 +95,7 @@ static void drm_sched_scheduler_queue_overhead(struct kunit *test)
>>  
>>  	/* Wait with a safe margin to avoid every failing. */
>>  	done = drm_mock_sched_job_wait_finished(job,
>> -						usecs_to_jiffies(total_us) * 5);
>> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>>  	end = ktime_get();
>>  	KUNIT_ASSERT_TRUE(test, done);
>>  
>> @@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct kunit *test)
>>  
>>  	/* Wait with a safe margin to avoid every failing. */
>>  	done = drm_mock_sched_job_wait_finished(job,
>> -						usecs_to_jiffies(total_us) * 5);
>> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>>  	end = ktime_get();
>>  	KUNIT_ASSERT_TRUE(test, done);
>>  
>